CMU/SEI-87-TR-1 3 
ESD-TR-87-114 

Carnegie-Mellon  University 

Software  Engineering  Institute 


Seeking  the  Balance  Between  Government  and 
Industry  Interests  In  Software  Acquisitions 

Volume  i: 

A  Basis  for  Reconciling  DoD  and  Industry  Needs 
for  Rights  In  Software 


Anne  C.  Martin 
Kevin  Deasy 


June  1987 


Technical  Report 

CMU/SEI-87-TR-13 
ESD/TR-87-114 
June  1987 


Seeking  the  Balance  Between  Government  and 
Industry  Interests  in  Software  Acquisitions 

Volume  I: 

A  Basis  for  Reconciling  DoD  and  Industry  Needs 

for  Rights  in  Software 


Anne  C.  Martin 
Kevin  Deasy 

Software  Rights 
in  Data  Project 


Approved  for  public  release. 
Distribution  unlimited. 


Software  Engineering  Institute 

Carnegie  Mellon  University 
Pittsburgh,  Pennsylvania  15213 


This  technical  report  was  prepared  for  the 

SEI  Joint  Program  Office 
ESD/XRS 

Hanscom  AFB,  MA  01731 

The  ideas  and  findings  in  this  report  should  not  be  construed  as  an  official  DoD 
position.  It  is  published  in  the  interest  of  scientific  and  technical  information 
exchange. 

Review  and  Approval 

This  report  has  been  reviewed  and  is  approved  for  publication. 


FOR  THE  COMMANDER 


Daniel  Burton 

SEI  Joint  Program  Office 


This  work  was  sponsored  by  the  Department  of  Defense. 

Copyright  ©  1987  Software  Engineering  Institute 


This  document  is  available  through  the  Defense  Technical  Information  Center.  DTIC  provides  access  to  and  transfer  of 
scientific  and  technical  information  for  DoD  personnel,  DoD  contractors  and  potential  contractors,  and  other  U.S. 
Government  agency  personnel  and  their  contractors.  To  obtain  a  copy,  please  contact  DTIC  directly:  Defense  Technical 
Information  Center,  Attn:  FDRA,  Cameron  Station,  Alexandria,  VA  22304-6145. 

Copies  of  this  document  are  also  available  through  the  National  Technical  Information  Services.  For  information  on 
ordering,  please  contact  NTIS  directly:  National  Technical  Information  Services,  U.S.  Department  of  Commerce, 
Springfield,  VA  22161. 


Table  of  Contents 


1.  Introduction  1 

2.  Issues  5 

2.1 .  Software  Developed  at  Government  Expense  5 

2.1.1.  Present  Policy  5 

2.1 .2.  Competing  Interests  of  the  DoD  and  Private  Industry  5 

2.1 .3.  Balancing  of  Interests  7 

2.2.  Software  Developed  at  Private  Expense  10 

2.2.1.  Present  Policy  10 

2.2.2.  Competing  Interests  of  the  DoD  and  Private  Industry  1 1 

2.2.3.  Balancing  of  Interests  13 

2.3.  Software  Developed  Using  a  Mix  of  Government  and  Private  Funds  15 

2.3.1 .  Present  Policy  1 6 

2.3.2.  Competing  Interests  of  the  DoD  and  Private  Industry  16 

2.3.3.  Balancing  of  Interests  17 

3.  Conclusion  23 

Bibliography  25 

Appendix  A:  Working  Group  A,  Intellectual  Property  Requirements  for  27 

Software  Maintenance  and  Enhancement 

Appendix  B:  Working  Group  B,  The  Scope  of  a  Software  Rights  Policy  39 

Appendix  C:  Working  Group  C,  Mixed  Funding  Alternatives  49 

Appendix  D:  Summary  of  Software  Rights  in  Data  Survey  61 

Tables  67 


CMU/SEI-87-TR-13  June  1987  I 


II 


June  1987 


CMU/SEI-87-TR-1 3 


List  of  Figures 

Figure  2-1:  Proposed  Mixed  Funding  Approach  19 

Figure  1 :  Model  Used  in  Defining  "Developed"  54 

Figure  2:  Proposed  Mixed  Funding  Approach  57 


CMU/SEI-87-TR-13 


June  1987 


iii 


Acknowledgements 

The  authors  are  indebted  to  Professor  Pamela  Samuelson  of  the  University  of  Pittsburgh 
School  of  Law  for  her  insights,  wisdom  and  patient  advice.  We  also  acknowledge  the  sub¬ 
stantial  contribution  of  Dr.  Robert  Glushko  of  the  Software  Engineering  Institute  who  guided 
our  efforts  in  conducting  the  Software  Rights  in  Data  survey,  and  who  assisted  in  presenting 
the  summary  of  the  results  of  that  survey. 

Our  gratitude  also  goes  to  Mr.  Jeffrey  Morelia  and  Ms.  Karen  Lewis  of  the  Software  Engi¬ 
neering  Institute  for  their  assistance  in  preparing,  formatting,  and  editing  this  work.  Without 
their  diligent  efforts,  operating  under  extremely  limiting  time  constraints,  this  effort  could  not 
have  been  as  successful  as  it  has  been. 


Seeking  the  Balance 

Between  Government  and  Industry  Interests 
in  Software  Acquisitions 

Volume  I: 

A  Basis  for  Reconciling  DoD  and  Industry  Needs 
for  Rights  in  Software 


Abstract:  The  policy  under  which  the  Department  of  Defense  (DoD)  acquires 
rights  in  software  and  technical  data  has,  in  the  past,  been  imbalanced  in  the 
direction  of  obtaining  more  rights  than  necessary  to  meet  its  needs.  As  noted  by 
the  Packard  Commission,  a  more  balanced  policy  is  in  the  interests  of  both  the 
DoD  and  industry.  The  DoD  has  recently  adopted  a  new  policy  for  acquiring  rights 
in  technical  data,  and  is  developing  a  separate  policy  for  acquiring  rights  in  soft¬ 
ware.  This  report  offers  several  recommendations  for  achieving  a  balanced  policy 
as  to  government  funded  software,  privately  funded  software,  and  mixed  funding 
software  that  will  meet  the  mission  needs  of  the  DoD  while  enabling  contractors  to 
protect  their  proprietary  interests,  and  commercialize  their  software  products. 


1.  Introduction 

The  President’s  Blue  Ribbon  Commission  on  Defense  Management  (Packard  Commission) 
and  Congress  in  recent  legislation  have  urged  the  Department  of  Defense  (DoD)  to  reex¬ 
amine  its  standard  policy  for  acquiring  rights  in  software  and  technical  data  that  have  been 
prepared  at  government  expense,  at  private  expense  and  with  mixed  funds  to  find  the  ap¬ 
propriate  balance  between  government  and  industry  interests  in  such  acquisitions.  Finding 
the  "delicate  and  necessary  balance"  [Packard,  p.  64]  that  will  both  foster  innovation  and 
meet  the  DoD’s  needs  is  difficult  to  implement.  The  DoD  has  recently  adopted  a  new  set  of 
technical  data  regulations  which  strikes  a  more  equitable  balance  between  government  and 
industry,  and  is  now  working  on  fine-tuning  its  software  rights  policy.  This  report  is  aimed  at 
assisting  the  DoD  in  finding  that  delicate  balance  as  to  software.  Because  of  significant 
differences  between  software  and  technical  data,  the  balance  for  software  may  not  be  the 
same  as  for  technical  data  [TR-2  87]. 

This  report  has  been  prepared  by  the  Software  Engineering  Institute  to  provide  input  to  the 
Software  Subcommittee  of  the  Defense  Acquisition  Regulatory  (DAR)  Council  in  its  efforts  to 
develop  a  new  software  rights  policy  for  the  DoD.  The  report  consists  of  two  volumes,  and 
is  based  on  an  integration  of  the  findings  of  the  Software  Rights  in  Data  Project .  Volume  I 
summarizes  research  conducted  to  ascertain  the  respective  needs  and  concerns  of  the  DoD 
and  private  industry,  while  Volume  II  is  the  result  of  a  consulting  effort  by  the  law  firm  of 
Shea  and  Gardner  of  Washington,  D.C.,  and  presents  commercial  models  for  protecting 
software  in  contracts  with  government  agencies. 
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Research  conducted  by  the  project  has  included  a  broad-based  survey  in  which  the  DoD 
and  industry  participants  provided  information  regarding  their  needs  and  concerns  with 
respect  to  rights  in  software  and  technical  data.  Interviews  were  conducted  to  follow  up  on 
points  raised  in  the  survey.  Indeed,  the  project  was  able  to  build  upon  a  research  base  of 
almost  200  interviews  of  both  industry  and  government  representatives  compiled  during  the 
two-year  existence  of  its  predecessor,  the  Software  Licensing  Project.  In  addition,  the  proj¬ 
ect  conducted  a  workshop  at  which  more  than  50  individuals,  with  balanced  representation 
from  the  public  and  private  sectors,  addressed  critical  technical  data/software  rights  issues 
in  an  effort  to  achieve  a  consensus  as  to  ways  in  which  their  respective  interests  could  be 
balanced. 

In  each  of  the  sections  below,  this  volume  proceeds  by  first  analyzing  present  DoD  policy, 
then  considering  contrasting  government  and  industry  needs  and  finally,  indicating  ways  in 
which  the  interests  of  government  and  industry  can  be  balanced.  The  three  sections  deal 
respectively  with  policy  as  to  software  developed  at  government  expense,  software  devel¬ 
oped  at  private  expense,  and  software  developed  with  mixed  funds. 

Section  2.1  recommends  that  the  DoD  adopt  a  different  standard  policy  as  to  software  de¬ 
veloped  entirely  or  mainly  with  government  funds.  The  DoD  does  not  need  more  than  gov¬ 
ernment  purpose  rights  to  fulfill  its  mission,  or  achieve  competition.  The  DoD  should  either 
adopt  a  policy  making  government  purpose  rights  standard,  or  it  should  include  sufficient 
flexibility  to  permit  contracting  officers  to  freely  obtain  less  than  unlimited  rights  when  such 
rights  are  adequate  to  meet  DoD’s  needs. 

Section  2.2  recommends  that  the  DoD  retain  "restricted  rights"  as  the  standard  package  of 
rights  acquired  in  software  developed  at  private  expense,  but  with  added  flexibility  to  permit 
contracting  personnel  to  accept  less  than  the  four  minimum  rights  where  appropriate  to  en¬ 
able  the  DoD  to  obtain  innovative  proprietary  technology.  A  directed  license/escrow  ar¬ 
rangement,  which  may  be  considered  less  than  minimum  rights,  is  suggested  as  an  ap¬ 
proach  to  supporting  privately  developed  software.  To  further  balance  the  needs  of  the  DoD 
and  industry  with  respect  to  proprietary  software  technology,  it  is  recommended  that  the 
DoD  acquire  software  documentation  with  the  same  set  of  rights  as  are  applied  to  machine 
readable  code. 

Section  2.3  recommends  that  the  DoD  acquire  no  more  than  a  government  purpose  license 
in  software  developed  with  mixed  funds.  Where  public  funds  account  for  90%  or  more  of  the 
development  costs,  software  should  be  considered  to  have  been  developed  at  government 
expense.  Conversely,  where  private  funds  make  up  90%  or  more  of  the  development  costs, 
software  should  be  considered  to  have  been  developed  at  private  expense.  Where  govern¬ 
ment  and  industry  contributions  are  more  closely  apportioned,  mixed  funding  treatment 
would  be  appropriate.  Additionally,  with  respect  to  defining  the  term  "developed"  for  pur¬ 
poses  of  determining  if  software  has  in  fact  been  developed  at  private  expense,  an  ap¬ 
proach  is  offered  that  involves  testing,  but  provides  that  if  testing  under  a  government  con¬ 
tract  results  in  no  significant  modifications,  the  software  will  be  considered  to  have  been 
developed  at  private  expense. 
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The  recommendations  presented  in  Volume  I  of  this  report  would  achieve  the  delicate 
balance  between  the  interests  of  government  and  industry  with  respect  to  software  devel¬ 
oped  with  government  funds,  software  developed  with  private  funds,  and  software  devel¬ 
oped  with  mixed  funding.  Volume  II  presents  background  material  that  will  aid  the  DoD  in  its 
implementation  of  a  new  software  rights  policy. 
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2.  Issues 


2.1 .  Software  Developed  at  Government  Expense 

The  Department  of  Defense  does  not  need  unlimited  rights  in  software  developed  wholly  at 
government  expense.  Government  purpose  rights  will  satisfy  DoD’s  mission  needs  and  al¬ 
low  the  DoD  to  achieve  competition  for  maintenance  and  enhancement.  If  the  DoD  chooses 
to  retain  a  standard  set  of  rights  for  software  developed  at  government  expense,  it  should 
make  government  purpose  rights  the  standard.  If,  on  the  other  hand,  it  is  unwilling  to  adopt 
government  purpose  rights  as  the  norm,  it  should  provide  the  flexibility  to  permit  procure¬ 
ment  personnel  to  freely  negotiate  for  fewer  rights  in  order  to  achieve  other  goals.  This  will 
give  industry  greater  incentive  to  do  business  with  the  DoD,  and  to  commercialize  the  soft¬ 
ware,  which  will  contribute  to  increased  innovation. 

2.1.1.  Present  Policy 

The  DoD  currently  claims  unlimited  rights  in  all  software  and  related  documentation  that  has 
been  developed  to  any  extent  with  government  funds.  Unlimited  rights  are  defined  as  the 
"rights  to  use,  duplicate,  release,  or  disclose,  technical  data  or  computer  software  in  whole 
or  in  part,  in  any  manner  and  for  any  purpose  whatsoever,  and  to  have  or  permit  others  to 
do  so  [DFARS,  Sec  227.471]."  This  does  not  mean  that  the  government  acquires  ownership 
of  the  intellectual  property  interests  in  software,  but  only  a  very  broad  license  to  use  it  (which 
includes  the  right  to  disseminate  the  software  and  its  documentation  to  third  parties  outside 
the  government  for  any  purpose)  [TR-1  86,  p.  24-26].  Under  the  previous  data  rights  policy, 
contracting  officers  had  no  flexibility  to  negotiate  for  less  than  unlimited  rights,  even  when  it 
would  have  been  in  the  interests  of  both  government  and  industry  to  do  so,  unless  they 
obtained  a  deviation.  Because  unlimited  rights  essentially  negate  the  probability  of  commer¬ 
cializing  software,  the  software  industry  viewed  the  policy  as  imbalanced.  Further,  the  fact 
that  these  exceptionally  broad  rights  in  the  government  were  triggered  in  every  case  except 
where  the  development  of  the  software  had  been  100%  privately  funded  made  the  im¬ 
balance  seem  even  more  pronounced.  The  recent  revisions  to  the  technical  data  regula¬ 
tions  [DFARS,  Sec.  227.4]  attempt  to  introduce  flexibility  in  these  areas.  However,  as  noted 
below,  these  revisions  may  not  be  sufficient  to  balance  government  and  industry  interests  in 
the  software  arena. 

2.1.2.  Competing  Interests  of  the  DoD  and  Private  Industry 
2.1 .2.1.  Government  Needs 

A  primary  need  of  the  government  is  to  obtain  high  quality  software.  The  government  also 
needs  to  be  able  to  maintain  and  enhance  (or  support),  as  well  as  reprocure  software.  Be¬ 
cause  of  software’s  highly  modifiable  nature,  software  support  is  not  limited  to  correcting 
software  errors  or  "bugs,"  but  also  includes  adding  new  functions  and  adapting  the  software 
to  environmental  changes.  The  DoD  thus  needs  a  right  to  create  derivative  software 
[Proposal  86,  Ch.  2].  The  sophisticated  nature  of  the  support  function  increases  the  need 
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to  transfer  the  developer’s  expertise,  which  is  embodied  in  the  software’s  source  code,  doc¬ 
umentation,  and  development  tools,  to  support  personnel.  (See  Survey,  Appendix  D.)  Since 
software  support  within  the  DoD  may  be  carried  out  by  third  party  support  contractors  as 
well  as  by  DoD  personnel,  the  DoD  often  needs  sufficient  rights  to  enable  it  to  disclose  sup¬ 
port  technology  to  third  parties  outside  DoD. 

Some  DoD  personnel  have  expressed  concern  that  obtaining  less  than  unlimited  rights  may 
pose  an  administrative  burden  for  the  DoD  in  that  it  would  then  be  obligated  to  monitor  and 
protect  the  proprietary  interest  created  in  the  developer.  It  has  also  been  noted  that  third 
party  contractors  may  be  reluctant  to  accept  software  with  proprietary  markings  due  to  con¬ 
cerns  that  they  may  be  exposing  themselves  to  claims  of  misappropriation.  Furthermore, 
unlimited  rights  may  have  some  economic  advantage  to  the  DoD  in  that  the  ability  to  dis¬ 
seminate  government  funded  software  to  other  government  contractors  for  later  commer¬ 
cialization  may  provide  the  DoD  some  negotiating  leverage.  Nonetheless,  a  flexible  policy 
under  which  procurement  personnel  would  generally  obtain  government  purpose  rights 
would  enable  them  to  negotiate  favorable  arrangements  while  ensuring  that  the  DoD  has 
sufficient  rights  to  meet  its  primary  needs. 

2.1 .2.2.  Industry  Needs 

The  software  industry  needs  to  be  able  to  recoup  its  investment  in  developing  and  commer¬ 
cializing  software.  Even  if  the  developer  obtains  money  from  the  government  for  software 
development,  the  developer  will  use  its  production  facility,  which  may  include  tools,  docu¬ 
mentation  and  development  expertise  created  with  substantial  private  investment.  In  order 
to  succeed,  the  contractor  must  be  able  to  protect  the  competitive  edge  provided  by  its  pro¬ 
duction  facility,  and  recoup  its  investment  through  the  sale  or  licensing  of  its  products.  (See 
Recommendations,  Appendix  A.) 

Many  software  developers  contend  that  DoD’s  broad  claim  of  unlimited  rights  in  government 
funded  software  serves  as  a  disincentive  to  doing  business  with  the  DoD.  They  fear  that, 
since  unlimited  rights  confer  upon  the  DoD  the  right  to  disclose  the  software  and  its  related 
documentation  to  anyone,  including  their  competitors,  providing  such  technology  to  the  DoD 
may  lessen  their  competitive  edge.  Further,  unlimited  rights  empowers  the  government  to 
inject  a  contractor’s  trade  secrets  into  the  public  domain,  thus  undermining  the  potential 
commercial  market  for  the  software. 

Consequently,  DoD’s  data  rights  policy  reduces  the  developer’s  incentive  to  commercialize 
and  market  technology  because  the  contractor  does  not  hold  the  exclusive  right  to  commer¬ 
cialize.  Since  the  developer  is  generally  in  a  better  position  than  the  DoD  to  transition  this 
technology  through  commercialization,  the  DoD  should  confine  its  acquisition  of  rights  in 
government  funded  software  to  those  needed  to  meet  its  legitimate  needs  and  goals,  rather 
than  being  concerned  with  rights  to  disseminate  technology. 
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2.1.3.  Balancing  of  Interests 


2.1 .3.1.  What  policy  goals  justify  dissemination  of  software  developed  at 
government  expense? 

The  balancing  of  DoD’s  mission  needs  with  industry’s  need  to  commercialize  software  tech¬ 
nology  requires  an  examination  of  DoD’s  underlying  policy  goals.  There  was  consensus 
among  participants  at  the  Software  Rights  in  Data  Workshop  that  maintenance  and  en¬ 
hancement,  reuse  and  competitive  reprocurement  are  appropriate  policy  goals  for  the  DoD 
in  acquiring  government  funded  software.  However,  the  DoD  also  has  an  interest  in  encour¬ 
aging  contractors  to  develop  innovative  software  technology  for  possible  government  use 
[DFARS  Sec.  227-472-1  (b)]. 

While  workshop  participants  recognized  that  there  may  be  some  cases  in  which  dissemi¬ 
nation  of  software  developed  at  government  expense  may  be  an  appropriate  DoD  goal,  they 
also  acknowledged  that  the  original  developer  is  generally  in  the  best  position  to  commer¬ 
cialize  software  because  of  its  core  of  development  expertise,  and  its  greater  incentive  to  do 
so.  A  policy  allowing  the  developer  to  retain  exclusive  rights  to  commercialize  software  pro¬ 
vides  a  powerful  incentive  for  investment  of  venture  capital  required  for  further  development, 
adaptation  to  commercial  applications  and  widespread  commercial  use.  Since  it  is  in  DoD’s 
interest  to  stimulate  private  investment  in  the  commercialization  of  government  funded  soft¬ 
ware  and  to  encourage  the  development  of  innovative  technology,  it  should  adopt  a  govern¬ 
ment  purpose  license  approach. 

2.1. 3.2.  What  Is  the  scope  of  rights  the  DoD  requires  in  order  to  achieve  its 
mission  needs  with  respect  to  software  developed  at  government 
expense? 

The  DoD  can  meet  its  needs,  in  most  cases,  by  acquiring  government  purpose  rights. 
Workshop  participants  concluded  that  DoD’s  primary  needs  with  respect  to  government 
funded  software  are  maintenance  and  enhancement  (support),  and  reprocurement.  The  so¬ 
phisticated  nature  of  software  support,  in  conjunction  with  DoD’s  unique  mission,  and  the 
requirement  for  competition,  often  necessitates  the  dissemination  of  the  developers’  tech¬ 
nology  to  meet  these  needs.  Because  software  developers  want  to  retain  the  exclusive  right 
to  commercialize  the  technology,  they  are  reluctant  to  give  the  DoD  broad  unlimited  rights  to 
disclose  and  disseminate  it  to  whomever  and  for  whatever  purpose  the  DoD  might  choose. 

Industry’s  needs  are  not,  however,  inconsistent  with  the  government’s  needs  with  respect  to 
software  developed  at  government  expense.  Workshop  participants  reached  consensus 
that  the  DoD  does  not  always  need  broad  unlimited  rights  for  purposes  of  maintenance, 
enhancement,  and  reprocurement  of  government  funded  software.  (See  Recommendations, 
Appendix  B.)  Although  it  was  not  recommended  that  the  unlimited  rights  concept  be 
eliminated,  participants  advocated  the  adoption  of  a  more  flexible  approach  to  acquiring 
rights  in  software  developed  at  government  expense.  It  was  recommended  by  one  of  the 
working  groups  (Working  Group  A)  that  procurement  personnel  be  given  the  flexibility  to 
negotiate  for  less  than  unlimited  rights,  (for  example,  rights  restricted  to  a  particular  agency 
or  project)  in  order  to  achieve  other  goals  in  a  software  procurement. 
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There  was  consensus  that  a  government  purpose  license  would  enable  the  DoD  to  meet  its 
needs,  provided  the  developer  agrees  to  permit  dissemination  to  third  parties  for  mainte¬ 
nance,  enhancement  and  competitive  reprocurement.  Working  Group  B  defined  this  as  a 
license  granting  the  government  the  rights  to  copy,  disclose,  enhance,  maintain,  modify,  pre¬ 
pare  derivative  works  or  otherwise  use  the  software  for  government  purposes.  Government 
purposes  would  exclude  any  action,  including  unrestricted  public  dissemination,  that  would 
detract  from  the  commercial  value  to  the  developer.  (See  Recommendations,  Appendix  B.) 

Thus,  a  government  purpose  license  would  not  preclude  dissemination  to  third  parties  for 
competitive  purposes,  provided  they  agreed  not  to  use  the  software  for  commercial  pur¬ 
poses.  There  was  considerable  discussion  as  to  how  to  enforce  an  agreement  by  a  third 
party  contractor  not  to  commercialize  or  further  disclose  software  technology  in  its  posses¬ 
sion.  Although  it  was  agreed  that  associate  contractor  nondisclosure  agreements  were  the 
preferred  method  of  enforcing  a  government  purpose  license,  it  was  recognized  that  in  some 
instances  the  developer’s  retention  of  a  copyright  in  the  software  would  sufficiently  protect 
his  or  her  interests. 

2.1 .3.3.  What  approach  should  the  DoD  adopt  for  obtaining  rights  in  software 
developed  at  government  expense? 

The  acquisition  of  unlimited  rights  as  a  standard,  inflexible  policy  for  software  developed  at 
government*  expense  should  be  eliminated.  Such  a  policy  is  incompatible  with  commer¬ 
cialization  of  publicly  funded  software  because  the  government  is  in  a  position  to  undercut 
the  developer's  exclusive  rights  to  commercialize  the  technology.  Since  commercialization 
is  likely  to  result  in  better  quality  software  for  the  DoD,  and  government  purpose  rights  will 
enable  the  DoD  to  satisfy  its  primary  needs,  it  is  recommended  that  if  the  DoD  desires  one 
standard  approach  for  obtaining  government  funded  software,  it  adopt  government  purpose 
license  rights  as  the  standard.  This  does  not  require  that  the  unlimited  rights  concept  be 
wholly  eliminated.  The  policy  could  be  flexible  enough  to  allow  contracting  officers  to  nego¬ 
tiate  for  unlimited  rights  when  an  express  determination  has  been  made  that  these  rights  are 
needed.  Thus,  the  DoD  can  still  acquire  unlimited  rights  when  they  are  essential  to  meet  its 
needs. 

In  the  event  the  DoD  chooses  not  to  adopt  government  purpose  rights  as  its  standard,  it  is 
recommended  that  greater  flexibility  be  incorporated  into  the  unlimited  rights  concept  to  per¬ 
mit  the  contracting  officer  to  negotiate  for  less  than  unlimited  rights.  For  example,  in  those 
instances,  where  the  government  does  not  need  unlimited  rights,  government  purpose  rights 
would  be  acquired.  In  those  cases  where  the  government  acquires  a  government  purpose 
license  in  publicly  funded  software  which  is  later  successfully  commercialized,  there  could 
be  flexibility  for  the  DoD  to  negotiate  to  receive  benefits  from  subsequent  sales.  (See  Rec¬ 
ommendations,  Appendix  A.) 

The  adoption  of  a  flexible  approach,  which  retains  "unlimited  rights"  as  the  norm  could  pose 
some  problems.  Under  such  a  policy,  inexperienced  or  cautious  contracting  personnel  may 
be  reluctant  to  depart  from  the  norm.  Thus,  it  is  possible  that  this  approach,  as  implemented 
by  procurement  personnel,  may  be  little  improvement  over  an  inflexible  unlimited  rights  stan- 
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dard,  unless  incentives  are  provided  to  encourage  contracting  personnel  to  take  advantage 
of  the  added  flexibility  where  appropriate. 

The  new  technical  data  regulations  take  the  first  step  toward  a  flexible  approach  in  providing 
that  in  those  cases  where  the  DoD  would  normally  obtain  unlimited  rights,  it  may  agree  to 
waive  those  rights  provided  that  it  receives,  as  a  minimum,  a  royalty-free  government  pur¬ 
pose  license.  However,  a  balanced  approach  for  government  funded  software  will  require 
more  than  a  waiver  provision.  The  policy,  provisions,  procedures  and  implementing  instruc¬ 
tions  must  be  crafted  so  as  to  encourage  procurement  personnel  to  acquire  only  the  rights 
which  are  essential  to  meet  government  needs.  The  adoption  of  government  purpose  li¬ 
cense  rights  as  the  standard  for  government  funded  software  or,  alternatively,  a  more  flex¬ 
ible  acquisition  policy  would  successfully  balance  public  and  private  sector  interests.  The 
government  purpose  license  would  afford  the  DoD  the  wide  range  of  rights  needed  to  ac¬ 
complish  its  mission  objectives.  At  the  same  time,  it  would  limit  these  rights  so  as  to  ex¬ 
clude  any  action  which  would  detract  from  the  software’s  commercial  value  to  the  developer, 
thereby  preserving  his  or  her  incentive  to  transition  the  technology.  It  is  in  the  DoD’s  interest 
to  provide  such  incentives  to  software  developers  to  continue  to  produce,  and  license  to  the 
DoD,  the  most  innovative  software  technology  [TR-2  87]. 

2.1 .3.4.  Conclusion 

Although  the  technical  data  policy  retains  unlimited  rights  in  government  funded  software  as 
the  norm,  its  recognition  that  the  DoD  may  not  always  need  unlimited  rights  in  every  acquisi¬ 
tion  is  a  first  step  toward  striking  the  balance  advocated  by  the  Packard  Commission.  Given 
the  unique  nature  of  software,  the  attainment  of  this  balance  is  even  more  critical  in  the 
software  rights  policy.  The  adoption  of  government  purpose  rights  as  the  standard  set  of 
rights  for  publicly  developed  software  would  be  a  fresh  approach  which  would  meet  the 
DoD’s  primary  needs  while  fostering  further  development  and  commercialization  of  publicly 
developed  technology.  The  alternative  approach  could  also  balance  the  DoD  and  industry 
needs  provided  the  policy  is  carefully  structured  so  as  to  encourage  flexibility  in  software 
acquisitions. 
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2.2.  Software  Developed  at  Private  Expense 

The  viability  of  privately  developed  software  as  a  commercial  product  depends  on  the 
developer’s  ability  to  restrict  access  to  that  software.  Although  industry  is  concerned  with 
limiting  the  distribution  of  proprietary  object  code,  it  is  especially  sensitive  about  protecting 
the  software  source  code,  documentation  and  development  tools.  These  items,  which  are 
created  at  substantial  private  investment,  are  regarded  as  the  developer’s  "crown  jewels" 
which  afford  him  his  competitive  edge.  The  current  policy,  under  which  the  DoD  may  claim 
government  wide  rights  in  documentation,  threatens  the  trade  secrets  incorporated  therein. 
The  resulting  imbalance  significantly  impedes  the  DoD’s  acquisition  of  the  most  innovative 
developed  software.  As  a  means  of  rectifying  this  imbalance,  this  section  offers  a  directed 
licensing/escrow  clause  which  will  satisfy  DoD’s  need  for  assurance  of  adequate  software 
support,  while  protecting  industry’s  proprietary  technology. 

In  addition  to  encouraging  the  structuring  of  creative  support  arrangements,  this  section  also 
recommends  that  software  documentation  and  object  code  be  governed  by  the  same  set  of 
rights,  and  that  more  flexibility  be  injected  into  the  policy.  Since  these  recommendations 
represent  a  more  balanced  treatment  of  DoD’s  and  industry’s  needs,  it  is  urged  that  they  be 
incorporated  in  the  new  software  policy. 

2.2.1 .  Present  Policy 

The  current  regulations  provide  that  software  which  has  been  developed  at  private  expense 
is  acquired  by  the  DoD  with  restricted  rights.  These  rights  restrict  the  software’s  use  to  the 
computer  for  or  with  which  it  was  acquired,  and  allow  modification,  copying  for  safekeeping 
and  use  with  a  back-up  computer.  While  the  regulation  allows  the  government  to  negotiate 
to  acquire  additional  rights  which  are  not  inconsistent  with  the  four  minimum  rights,  it 
precludes  negotiation  below  this  minimum  "floor"  without  a  DAR  Council  deviation  [DFARS 
Sec.  227.481-2]. 

Under  existing  policy,  restricted  rights  apply  only  to  privately  developed  machine  readable 
code.  Since  documentation  is  treated  as  technical  data,  it  is  not  subject  to  the  same  set  of 
restricted  rights  as  the  machine  readable  code  but  rather  is  subject  to  limited  rights.  These 
give  the  DoD  the  right  to  use,  duplicate  and  disclose  the  software  throughout  the  govern¬ 
ment.  Moreover,  the  DoD  claims  broader  unlimited  rights  in  manuals  or  instructional 
materials  necessary  for  installation,  operation,  maintenance  or  training  purposes  [DFARS 
Sec.  227.472-5(d)(3)].  Since  virtually  all  software  documentation  may  be  construed  to  fall 
within  this  clause,  potentially  all  documentation  may  be  subject  to  an  unlimited  rights  claim, 
even  when  developed  entirely  with  private  funds  [TR-1  86]. 

The  policy’s  lack  of  flexibility  to  enable  the  structuring  of  creative  arrangements  to  acquire 
state  of  the  art  technology,  and  its  treatment  of  software  documentation  as  technical  data  fail 
to  recognize  that  software  by  its  very  nature  generates  different  DoD  and  industry  needs 
than  does  technical  data.  Accordingly,  a  policy  that  will  balance  those  needs  must  recog¬ 
nize  the  unique,  evolving  nature  of  the  product  that  shapes  them. 


10 


June  1987 


CMU/SEI-87-TR-13 


2.2.2.  Competing  Interests  of  the  DoD  and  Private  Industry 

2.2.2.1.  Government  Needs 

The  DoD  increasingly  relies  on  software  in  order  to  successfully  perform  its  worldwide  mis¬ 
sion.  Because  much  of  software’s  product  potential  is  still  untapped,  the  software  industry, 
spurred  by  increasing  demand,  is  constantly  producing  new  improvements  and  applications, 
rendering  earlier  technology  obsolete.  Many  of  these  innovations  are  capitalized  with 
private  funding.  Although  the  DoD  has  a  need  for  the  latest  "leading  edge"  software  tech¬ 
nology  in  many  mission  critical  areas,  it  has  become  increasingly  evident,  in  recent  years, 
that  the  DoD  has  not  been  able  to  access  the  most  innovative  privately  developed  software 
technology  to  the  extent  it  would  like. 

DoD’s  need  to  acquire  the  best  state  of  the  art  technology  is  not  always  compatible  with  its 
need  to  maintain  and  enhance  that  technology.  Reconciliation  of  these  two  needs  is  difficult 
to  achieve  within  the  context  of  a  software  policy  that  does  not  recognize  software’s  unique 
characteristics.  Unlike  technical  data,  software  is  a  dynamic  product  which  evolves  to  meet 
new  user  needs  throughout  its  life  cycle.  Thus,  a  successful  software  support  effort  requires 
access  to  the  developer’s  expertise  which  is  incorporated  into  his  documentation  and  devel¬ 
opment  tools  [TR-2  87].  Consequently,  developer  support  may,  in  many  cases,  be  the  most 
cost  effective,  efficient  means  of  maintaining  privately  developed  software.  - 

While  DoD  personnel  recognize  the  advantages  of  developer  support  for  privately  devel¬ 
oped  software,  many  feel  that  the  DoD  should  retain  an  organic  support  capability.  Addition¬ 
ally,  the  Competition  in  Contracting  Act  [CICA  84],  as  implemented,  tends  to  limit  developer 
support  and  increase  the  use  of  third  party  support  contractors  [TR-2  87].  Moreover,  even  if 
a  developer  support  concept  is  chosen  for  a  system,  provision  must  be  made  for  such  con¬ 
tingencies  as  a  developer’s  failing  to  perform  satisfactorily,  discontinuing  the  product  line,  or 
going  out  of  business.  Thus,  in  order  to  assure  the  DoD  of  adequate  support,  a  mechanism 
must  exist  to  make  the  developer’s  support  technology  available  to  those  who  will  assume 
the  support  role. 

A  software  rights  policy  that  is  more  consistent  with  software’s  technical  and  economic 
realities  will  enable  the  DoD  to  more  effectively  reconcile  its  need  for  the  best  software  with 
its  need  to  support  that  technology.  The  key  to  resolution  is  a  policy  that  is  flexible  enough 
to  accommodate  these  dual  interests,  while  at  the  same  time  satisfying  the  private  sector’s 
need  for  proprietary  protection. 

2.2.2.2.  Industry  Needs 

If  the  DoD  wants  to  be  able  to  acquire  the  most  innovative  software  that  industry  has  to 
offer,  it  must  develop  a  software  policy  that  will  accommodate  industry’s  need  to  protect  its 
substantial  investment  in  its  proprietary  technology.  In  order  to  forge  such  a  policy,  the  DoD 
must  recognize  that  software,  by  virtue  of  its  intrinsic  qualities,  gives  rise  to  a  set  of  devel¬ 
oper  needs  substantially  different  from  those  related  to  technical  data.  Unlike  technical 
data,  which  is  ancillary  to  a  hardware  product,  software  is  often  an  end  product  in  itself. 
Moreover,  the  design  documents,  requirements  documents,  source  code  and  other  data 
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which  are  generated  during  software  development  are  an  integral  part  of  that  software  prod¬ 
uct,  representing  significant  capital  investment.  Since  these  documents  embody  the  es¬ 
sence  of  the  software’s  design  and  structure,  their  unrestricted  disclosure  or  dissemination 
could  deprive  the  developer  of  his  competitive  edge  and  even  jeopardize  his  existence. 

The  current  regulatory  treatment  of  software  documentation  as  technical  data  ignores  the 
commercially  sensitive  nature  of  source  code  and  other  documentation.  The  risk  of  having 
their  valuable  proprietary  documentation  widely  disseminated  may  deter  many  companies 
from  licensing  such  documentation  to  the  DoD.  Industry  survey  participants  identified 
source  code,  design  documents,  and  designer's  notes  as  the  documentation  they  were  least 
likely  to  license.  (See  Survey,  Appendix  D.)  Moreover,  both  workshop  and  survey  partic¬ 
ipants  expressed  considerable  reluctance  to  license  privately  developed  tools  and  documen¬ 
tation  to  third  party  support  contractors  without  being  able  to  negotiate  license  terms  directly 
with  such  contractors.  This  underscores  the  need  for  a  policy  which  provides  flexibility  to 
negotiate  more  creative  arrangements  to  enable  privately  developed  software  to  be  ade¬ 
quately  supported. 

The  existing  policy’s  failure  to  recognize  industry’s  software  specific  needs  not  only  impacts 
how  the  DoD  may  support  software  it  has  already  acquired,  but  also  whether  it  can  access 
the  newest  state  of  the  art  technology.  Some  companies  are  oqly  willing  to  license  their 
proprietary  software  under  very  restrictive  terms.  If  these  terms  fall  below  the  floor  of 
"minimum  rights",  the  contracting  officer  must  obtain  a  DAR  Council  deviation  authorizing 
such  a  procurement.  This  requirement  is  viewed  by  some  industry  representatives  as  un¬ 
duly  restrictive  and  time  consuming.  The  net  effect  is  to  discourage  such  "deals"  which 
could  allow  the  DoD  to  gain  access  to  state  of  the  art  software  technology. 

The  extent  to  which  DoD’s  inflexible  data  rights  policy  is  costing  it  access  to  the  most  inno¬ 
vative  technology  was  examined  in  our  survey  of  industry  representatives.  (See  Survey, 
Appendix  D.)  Survey  results  indicated  that  industry  is  often  unwilling  to  license  privately  de¬ 
veloped  software  tools,  applications  software,  CAD/CAM  programs,  and  artificial  intelligence 
programs  to  the  DoD  because  of  its  data  rights  policy.  However,  an  overwhelming  majority 
(88%  of  respondents)  expressed  their  willingness  to  license  software  to  the  DoD  under  cer¬ 
tain  conditions.  These  were: 

•  Limitations  preventing  the  DoD  from  permitting  parties  outside  of  the  DoD  to 
make  use  of  or  see  the  software  or  documentation, 

•  Limitations  restricting  DoD’s  use  to  a  particular  site, 

•  Limitations  on  DoD’s  access  to  a  particular  type  of  technology  or  documenta¬ 
tion. 

While  these  results  confirm  the  private  sector’s  acute  sensitivity  to  disclosure  of  their 
privately  developed  technology,  they  also  reflect  industry  willingness  to  make  this  technol¬ 
ogy  available  to  the  DoD  under  certain  conditions.  The  challenge  in  developing  a  balanced 
policy  for  privately  developed  software  lies  in  formulating  a  policy  that  is  flexible  enough  to 
allow  the  DoD  to  acquire  the  most  innovative  software  technology  while  protecting  industry’s 
interests  in  such  technology. 
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2.2.3.  Balancing  of  Interests 

The  first  step  in  balancing  DoD’s  needs  with  those  of  industry  is  to  recognize  that  these 
needs  stem,  in  part,  from  the  intrinsic  nature  of  the  software  product.  Because  of  the  nature 
of  its  development  process,  software’s  structure  and  functions  are  embodied  in  its  source 
code  and  other  documentation,  which  may  be  the  very  "life  blood"  of  the  developer.  This 
generates  a  private  sector  need  to  protect  this  valuable  proprietary  material  from  wide¬ 
spread  dissemination.  However,  the  DoD  needs  access  to  development  documentation  and 
tools  in  order  to  benefit  from  another  one  of  software’s  properties  -  its  adaptability.  In  order 
to  maintain  and  enhance  the  software,  support  personnel  require  access  to  the  very  tech¬ 
nology  which  the  developer  is  most  reluctant  to  disclose  [TR-2  87]. 

In  order  to  accommodate  these  public  and  private  sector  concerns,  a  software  rights  policy 
must  adopt  a  more  balanced  approach  which  is  attuned  to  the  software  product’s  unique 
characteristics.  This  approach  can  be  implemented  by  providing  a  directed  licensing/escrow 
option  to  meet  DoD’s  support  needs,  eliminating  the  differential  treatment  of  software  and 
documentation  and  injecting  more  flexibility  into  the  policy. 

2.2.3.I.  How  can  a  software  rights  policy  be  structured  to  allow  the  DoD  to 
acquire  access  to  proprietary  technology? 

At  the  Software  Rights  in  Data  Workshop,  the  maintenance  and  enhancement  working 
group  (Group  A)  was  tasked  with  formulating  a  fresh  approach  to  supporting  privately  devel¬ 
oped  software.  There  was  consensus  that  a  major  advantage  to  the  government  in  acquir¬ 
ing  privately  developed  commercial  software  is  that  the  developer,  rather  than  the  govern¬ 
ment,  can  be  held  responsible  for  supporting  the  software.  Accordingly,  the  DoD  generally 
will  not  need  to  take  delivery  of  source  code  and  other  support  technology  although  it  will 
need  assurance  that  the  software  can  be  adequately  supported  by  the  original  developer  or 
a  responsible  third  party.  The  solution  offered  to  meet  this  need  was  the  development  of  an 
optional  conditional  directed  licensing  clause  which  includes  an  escrow  of  support  material. 

The  basic  principle  underlying  this  clause  Is  the  software  developer’s  agreement  to  license 
the  software  and  escrowed  material  to  a  responsible  third  party  to  perform  support  functions 
if  the  original  developer  is  unwilling  or  unable  to  do  so:  The  licensing  provision  would  be 
triggered  by  the  developer’s  unwillingness  or  inability  to  perform  support  functions  at  a 
reasonable  price.  Upon  notification  to  the  developer,  the  government  can  transfer  the  sup¬ 
port  functions  to  a  third  party  and  a  license  will  implicitly  be  granted  to  that  party  to  perform 
those  functions.  The  scope  of  the  third  party’s  rights  in  the  software  will  not  exceed  that  of 
the  government  under  the  original  contract  and  the  developer  retains  the  right  to  sue  the 
third  party  directly  under  the  license  if  the  latter  abuses  it. 

The  directed  licensing  clause  is  structured  to  work  in  conjunction  with  an  escrow  arrange¬ 
ment.  All  materials  necessary  to  regenerate  or  modify  the  software,  which  were  not 
delivered  to  the  government,  are  placed  into  escrow  at  the  time  the  object  code  is  delivered. 
The  developer  will  be  required  to  update  the  escrowed  documentation.  When  a  developer  is 
unwilling  or  unable  to  support  the  software  he  may  direct  release  of  the  escrowed  materials. 
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If  the  developer  contests  the  government’s  claim  that  the  conditions  for  escrow  release  are 
met,  there  must  be  a  finding  by  the  agency  head  that  the  DoD  has  a  valid  claim  for  release 
of  the  materials.  Upon  such  a  finding,  the  developer  will  be  notified  of  the  party  to  whom  the 
materials  were  released  and  instructed  to  negotiate  to  provide  technical  assistance  to  that 
party. 

This  approach  balances  DoD’s  need  for  assurance  of  adequate  support  with  industry’s  need 
for  protection  of  proprietary  information.  The  DoD  is  protected  in  securing  an  agreement 
from  the  developer  to  license  and  provide  transition  assistance  to  a  third  party.  Most  impor¬ 
tantly,  provision  is  made  to  enable  that  third  party  to  obtain  access  to  critical  support  docu¬ 
mentation.  Moreover,  this  methodology  can  be  tailored  to  meet  DoD’s  need  to  establish  an 
organic  support  capability.  In  addition  to  assuring  that  DoD’s  needs  are  met,  this  approach 
protects  the  developer’s  interests  in  that  he  is  not  initially  obligated  to  deliver  his  proprietary 
documentation  and  tools  to  the  DoD.  Third  parties  will  only  obtain  access  to  it  under  certain 
specified  conditions.  It  was  felt  that,  in  practice,  the  DoD  may  have  little  need  to  invoke  its 
rights  under  this  clause  since  its  very  existence  creates  a  powerful  incentive  for  the  devel¬ 
oper  to  seek  a  consensual  support  arrangement. 

In  addition  to  offering  creative  methodologies  to  meet  DoD’s  need  to  access  proprietary  sup¬ 
port  technology,  a  new  software  policy  should  also  provide  the  flexibility  for  the  DoD  to  ac¬ 
quire  innovative  software  technology.  Workshop  participants  recognized  that  situations  may 
arise  where  in  order  to  license  a  privately  developed  tool  or  artificial  intelligence  program, 
the  DoD  may  have  to  waive  one  of  its  four  minimum  restricted  rights.  Under  current  policy, 
the  contracting  officer  must  go  through  the  time  consuming  process  of  seeking  a  DAR  Coun¬ 
cil  deviation  in  order  to  consummate  such  a  deal.  Some  industry  representatives  viewed 
this  process  as  too  cumbersome  and  urged  the  adoption  of  an  intra-agency  approval  proc¬ 
ess  for  such  deviations.  Government  representatives  expressed  concern  over  allowing  field 
personnel  to  exercise  too  much  discretion  in  waiving  a  standard  minimum  right.  Although  no 
consensus  was  reached  on  this  issue,  a  policy  providing  for  a  more  expedited  intra-agency 
approval  process  for  "special  deals"  would  demonstrate  an  appreciation  of  industry’s  need 
to  protect  its  proprietary  technology,  while  encouraging  arrangements  which  would  increase 
DoD’s  access  to  such  innovative  technology.  The  policy  should  also  contain  enough  flexi¬ 
bility  to  allow  the  DoD  to  acquire  rights  restricted  to  a  particular  program. 

A  software  rights  policy  that  encourages  the  use  of  escrow,  directed  licensing,  program 
restricted  rights  and  other  creative  arrangements  would  facilitate  DoD’s  acquisition  and  sup¬ 
port  of  innovative  technology  while  protecting  industry’s  proprietary  interests.  The  incorpo¬ 
ration  of  these  methodologies  into  a  regulation  will  inject  a  new  flexibility  into  the  policy  that 
can  lead  to  a  better  balancing  of  industry’s  and  DoD’s  needs. 

2.2.3.2.  Is  there  a  set  of  minimum  rights  that  the  DoD  always  needs  to  acquire 
in  privately  developed  software  and  its  documentation? 

One  of  the  primary  reasons  for  the  current  policy’s  imbalance  stems  from  its  failure  to  treat 
software  documentation  as  a  vital  component  of  the  software  product  which  industry  has 
strong  interests  in  protecting.  Our  survey  indicated  significant  industry  and  government  con- 


14 


June  1987 


CMU/SEI-87-TR-13 


sensus  that  source  code,  user  manuals,  design  and  requirements  documents  be  included 
within  the  definition  of  the  term  software.  Working  Group  B  concurred  that  software  docu¬ 
mentation  should  be  treated  in  the  same  manner  as  the  related  software,  but  differentiated 
between  documentation  which  the  DoD  needs  broad  rights  to  disseminate,  and  documen¬ 
tation  which  includes  source  code,  algorithms,  process  formulae  and  flow  charts.  It  was 
recommended  that  user  manuals  (which  do  not  include  source  code,  algorithms,  processes, 
formulae,  or  flow  charts)  be  acquired  under  a  broad  government  purpose  license.  However, 
other  privately  developed  documentation  is  to  be  acquired  with  the  same  restricted  rights  as 
its  related  software. 

There  was  consensus  among  the  DoD  and  industry  workshop  participants  that  the  present 
set  of  minimum  restricted  rights  meets  both  sectors’  needs.  However,  it  was  recommended 
that  DoD’s  right  to  use  the  software  be  expanded  to  include  use  with  an  upwardly  com¬ 
patible  replacement  computer  in  those  instances  where  the  software  is  licensed  alone  in¬ 
stead  of  as  part  of  a  system. 

2.2.3.3.  Conclusion 

A  software  policy  which  balances  DoD’s  need  to  acquire  and  support  proprietary  technology 
with  industry’s  need  to  protect  such  technology  must  recognize  the  unique  nature  of  the 
software  product  whigh  shapes  those  needs.  Allowing  software  documentation  to  be 
governed  by  the  same  set  of  rights  as  object  code  would  more  accurately  reflect  the  tech¬ 
nical  and  economic  importance  of  documentation  to  the  developer.  This  opens  the  door  for 
the  structuring  of  an  optional  directed  licensing/escrow  clause  which  effectively  balances 
DoD’s  support  needs  with  industry’s  proprietary  needs.  The  incorporation  of  this  method¬ 
ology  into  a  software  policy,  in  conjunction  with  the  flexibility  to  negotiate  creative  licensing 
arrangements,  will  improve  DoD’s  ability  to  access  leading  edge  technology,  which  in  the 
long  run,  will  enhance  our  defense  capability. 


2.3.  Software  Developed  Using  a  Mix  of  Government  and 
Private  Funds 

Both  the  Packard  Commission  and  Congress  have  recommended  that  the  DoD  foster 
private  investment  by  adopting  a  more  balanced  approach  for  allocating  rights  in  software 
that  has  been  developed  using  a  mix  of  government  and  private  funds  [Packard,  p.  64] 
[National  Defense  Authorization  Act  for  Fiscal  Year  1987,  Sec.  953(a)(2)(E)],  There  are 
various  situations  that  should  be  considered  in  structuring  a  mixed  funding  approach.  For 
example,  a  software  product  may  have  been  brought  to  a  particular  point  of  development  at 
private  expense,  and  then  be  further  developed  or  modified  for  DoD  use  at  government  ex¬ 
pense.  This  section  recommends  that  the  DoD  obtain  government  purpose  rights  in  mixed 
funding  software,  with  the  flexibility  to  negotiate  for  lesser  rights  where  appropriate,  and  sug¬ 
gests  an  approach,  different  from  that  adopted  in  the  recent  revision  of  the  technical  data 
regulations,  for  determining  when  software  should  be  treated  as  having  been  developed  at 
government  expense,  at  private  expense,  and  with  mixed  funds. 
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2.3.1.  Present  Policy 

Until  May  18,  1987,  the  DoD  had  no  mixed  funding  policy.  Since  May  18,  the  DoD  has  had 
a  mixed  funding  policy  for  technical  data.  The  question  is  whether  the  policy  adopted  for 
technical  data  should  apply  to  software,  or  whether  there  should  be  a  different  mixed  fund¬ 
ing  policy  for  software. 

Historically,  even  the  most  minor  amount  of  government  money  spent  on  software  devel¬ 
opment  has  been  deemed  sufficient  to  give  the  DoD  unlimited  rights.  The  approach 
adopted  for  technical  data  in  the  revised  DFARS  provides  that  only  those  situations  in  which 
a  contractor  contributes  more  than  50%  of  the  development  costs  can  be  treated  as  mixed 
funding  [DFARS,  Sec.  227.472-5(b)].  The  inflexibility  of  this  approach  raises  a  question  as 
to  whether  it  is  appropriate  for  software  that  has  been  developed  with  a  mix  of  government 
and  contractor  funds. 

2.3.2.  Competing  Interests  of  the  DoD  and  Private  Industry 

2.3.2.1 .  Government  Needs 

One  of  the  strongest  needs  of  the  DoD  is  to  obtain  good  technology.  As  was  noted  by  the 
Packard  Commission,  the  DoD  has  an  interest  in  encouraging  private  investment  that  might 
lead  to  the  development  of  innovative  software  technology  useful  to  the  DoD.  Additionally,  it 
is  in  DoD’s  interest  for  firms  to  commercialize  software  products  because  it  improves  the 
incentives  for  delivering  quality  products.  The  encouragement  of  greater  private  investment 
and  commercialization  is  likely  to  result  in  more  mixed  funding  situations. 

With  respect  to  mixed  funding  software,  as  with  software  developed  at  government  expense 
or  at  private  expense,  it  is  in  the  DoD's  interest  to  obtain  technology  that  can  be  maintained 
and  enhanced.  Further,  the  DoD  needs,  where  possible,  to  have  the  capability  to  perform, 
or  achieve  competition  for,  the  maintenance  and  enhancement  of  software  so  as  to  avoid 
being  locked  into  a  sole  source  position  with  the  original  developer.  The  DoD  thus  needs  a 
right  to  disseminate  software  for  competitive  purposes,  but  does  not  need  a  right  to  gener¬ 
ally  disseminate  software  technology. 

Moreover,  the  DoD  has  an  interest  in  minimizing  the  administrative  burdens  that  accompany 
restrictions  on  the  use  of  software.  The  administrative  burden  associated  with  safeguarding 
the  proprietary  interests  created  in  the  contractor  where  the  government  takes  less  than  un¬ 
limited  rights  was  noted  in  the  recent  revision  of  the  DFARS  technical  data  regulations 
[DFARS,  Sec.  227.472-5(b)]. 

2.3.2.2.  Industry  Needs 

The  DoD  may  disseminate  software  and  software  documentation  in  which  it  has  unlimited 
rights  outside  of  the  government  for  any  purpose.  Most  contractors  strenuously  object  to 
such  dissemination  because  of  fear  that  software  technology  they  have  developed  will  come 
into  the  possession  of  their  competitors,  thus  lessening  their  edge  in  the  marketplace.  Con¬ 
sequently,  many  contractors  refuse  to  make  their  most  innovative  technology  available  to 
the  DoD,  and  are  unwilling  to  modify  their  technology  so  as  to  make  it  useful  to  the  DoD. 
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Further,  the  harshness  of  a  policy  under  which  mixed  funding  situations  have  resulted  in  the 
DoD  obtaining  the  same  set  of  inflexible  unlimited  rights  as  has  been  acquired  in  software 
developed  exclusively  at  government  expense  has  led  to  a  reluctance  on  the  part  of  devel¬ 
opers  to  invest  private  resources  into  technology  that  might  benefit  the  DoD.  This  disincen¬ 
tive  is  particularly  true  with  respect  to  the  development  of  innovative  design  and  develop¬ 
ment  tools  which  might  make  the  development  process  more  effective  and  efficient.  (See 
Recommendations,  Appendix  A,  regarding  suggested  treatment  of  software  tools.) 

The  critical  point  is  that  the  DoD  is  losing  access  to  innovative  software  technology  which 
could  be  extremely  valuable  to  it  in  meeting  its  mission  needs.  For  example,  contractors 
participating  in  the  survey  conducted  by  the  project  indicated  that  approximately  65%  of  the 
time  they  are  unwilling  to  make  privately  developed  software  tools  available,  and  that  49%  of 
the  time  they  are  unwilling  to  make  privately  developed  applications  programs  available  due 
to  DoD’s  data  rights  policies.  This  indicates  that  the  present  policy  is  not  serving  the  best 
interests  of  the  DoD. 

Representatives  of  private  industry  have  also  expressed  considerable  dissatisfaction  with 
respect  to  DoD’s  treatment  of  technology  that  has  been  developed  to  a  point  at  private  ex¬ 
pense  and  is  then  modified  or  further  developed  using  public  funds.  The  DoD  policy  (at 
least  until  the  recently  released  revision  of  the  technical  data  regulations)  has  been  to  claim 
unlimited  rights  in  such  situations,  unless  the  modification  is  severable  from  the  privately 
funded  portion. 

2.3.3.  Balancing  of  Interests 

Increased  private  investment  in  the  development  of  software  products  is  in  the  interests  of 
both  the  DoD  and  industry.  Such  private  investment  will  result  in  a  greater  amount  of  soft¬ 
ware  that  is  developed  using  a  mix  of  government  and  private  funds.  It  is,  therefore,  essen¬ 
tial  to  the  fostering  of  increased  private  investment  that  the  DoD  adopt  an  equitable  policy 
for  obtaining  rights  in  mixed  funding  software. 

2.3.3.I.  Is  the  recently  implemented  mixed  funding  alternative  for  technical 
data  appropriate  for  software? 

The  mixed  funding  alternative  implemented  in  the  new  technical  data  regulations  provides 
that  if  1 )  the  contractor  contributes  more  than  50%  of  the  development  costs  and  agrees  to 
commercialize  the  item,  and  2)  the  contracting  officer  does  not  determine  that  the  govern¬ 
ment  requires  unlimited  rights,  the  DoD  will  obtain  "Government  Purpose  License  Rights" 
[DFARS,  Sec.  227.471].  Government  purpose  license  rights  appear  to  give  the  government 
rights  similar  to  unlimited  rights,  with  a  qualification,  similar  to  that  placed  on  software  that 
has  been  copyrighted  by  the  contractor,  that  any  use,  duplication,  or  disclosure  must  be  for 
government  purposes  only.  The  government  purpose  license  rights  provision  states  ex¬ 
plicitly  that  government  purposes  include  dissemination  for  obtaining  competitive  procure¬ 
ment,  but  do  not  include  permitting  a  third  party  to  use  the  item  for  commercial  purposes 
[DFARS,  Sec.  227.471]. 
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The  proposed  technical  data  provisions  of  the  Federal  Acquisition  Regulation  (FAR)  also 
include  a  mixed  funding  alternative  [FAR,  Subpart  27.4,  Sec.  27.408].  The  FAR  mixed 
funding  provision,  like  the  DFARS,  speaks  of  private  contributions  of  "approximately  50%" 
as  the  point  at  which  mixed  funding  treatment  might  be  indicated.  The  FAR  provision  is, 
however,  much  more  flexible  than  the  DFARS  in  that  it  uses  "approximately  50%"  merely  as 
a  guideline,  leaving  considerable  flexibility  to  contracting  personnel  to  determine  when  and 
how  use  of  the  mixed  funding  alternative  might  be  appropriate.  The  FAR  provision  also 
permits  individual  agencies  to  regulate  the  use  of  the  mixed  funding  alternative  in  their 
supplements. 

Because  the  revisions  to  the  DFARS  and  the  FAR  have  only  recently  been  released,  neither 
mixed  funding  approach  has  yet  been  tested  in  practice.  The  DFARS  provision,  however, 
appears  to  be  too  inflexible  to  be  applicable  to  software. 

Software  is  a  product,  unlike  technical  data  which  is  generally  produced  ancillary  to  the  de¬ 
velopment  of  a  product.  The  investment  in  developing  a  software  product  is  generally  sub¬ 
stantial,  and  must  be  recouped  through  the  sale  or  licensing  of  the  software  product. 
Indeed,  the  very  existence  of  the  company  may  depend  on  the  successful  marketing  of  the 
software  product.  The  cost  of  producing  technical  data,  on  the  other  hand,  is  generally 
recouped  through  the  sale  of  the  product  for  which  the  data  has  been  produced. 

Contractors  are,  therefore,  very  reluctant  to  invest  their  own  funds  into  the  development  of 
innovative  software  technology,  be  it  an  applications  program  or  design  and  development 
tools  to  aid  in  the  production  of  such  programs,  unless  they  can  feel  confident  of  their  ability 
to  adequately  recoup  such  investment.  A  rigid  application  of  a  50%  formula  would  not  take 
into  account  these  economic  realities  of  software  development.  A  more  flexible  approach  is 
required  to  create  the  necessary  incentives  to  encourage  private  investment  into  the  devel¬ 
opment  of  innovative  software  technology. 

2.3.3.2.  Under  what  circumstances  should  a  mixed  funding  alternative  apply? 

A  question  addressed  at  the  Software  Rights  in  Data  Workshop  was  whether  a  percentage 
based  formula  would  be  appropriate  for  software.  There  was  some  agreement  that  the  use 
of  terms  such  as  "substantial"  or  "material"  in  lieu  of  a  specific  percentage  might  be  too 
subjective,  and  would  probably  create  conflict  and  ultimately  evolve  to  a  point  where  the 
term  was  generally  associated  with  a  certain  percentage  anyway. 

A  suggestion  raised  at  the  workshop  that  appears  to  have  considerable  promise  was  that 
rather  than  setting  a  particular  percentage  as  a  dividing  line  between  government  funding 
and  mixed  funding,  it  might  be  appropriate  to  take  a  particular  percentage  at  both  ends  of 
the  government-private  continuum,  and  designate  the  area  in  between  as  mixed  funding. 
For  example,  the  policy  could  establish  that  where  less  than  10%  of  the  development  is 
privately  funded  (i.e.,  greater  than  90%  government  funded),  the  item  will  be  considered  to 
have  been  developed  at  government  expense.  Where  less  than  10%  of  the  development 
has  been  government  funded  (i.e.,  greater  than  90%  privately  funded),  the  item  will  be  con¬ 
sidered  to  have  been  privately  funded.  Finally,  where  government  and  private  funds  each 
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account  for  greater  than  10%  of  the  development  costs,  the  item  will  be  treated  under  the 
mixed  funding  alternative. 

Treated  as  Treated  as  Treated  as 

"at  Private  Expense"  Mixed  Funding  "at  Government  Expense" 


Such  an  approach  would  have  the  effect  of  setting  an  objective,  measurable  standard  for 
determining  the  appropriate  treatment  in  each  particular  case,  and  would  avoid  the  potential 
harshness  of  a  strict  dividing  line  approach.  Further,  it  would  establish  an  equitable  policy 
for  dealing  with  those  situations  in  which  the  contribution  of  one  of  the  parties  has  been 
relatively  slight,  such  as  those  instances  in  which  privately  developed  software  is  slightly 
modified  at  public  expense.  This  approach  would  thus  avoid  the  rigidity  of  the  strict  50% 
formula,  while  providing  somewhat  greater  structure  for  contracting  personnel  than  would 
the  highly  flexible  FAR  approach.  It  thus  seems  to  provide  a  reasonable  approach  to 
balancing  the  respective  interests  and  concerns  expressed  by  the  DoD  and  private  industry. 

It  should  be  noted,  however,  that  software  is  not  a  seamless  whole,  but  rather  is  often  com¬ 
posed  of  separable  units.  Indeed,  a  goal  of  the  Ada  language  initiative  is  to  increase  the 
use,  and  reuse,  of  separable  software  modules.  Contractors  may  be  able  to  use  and  reuse 
privately  developed  modules  as  part  of  a  larger  program.  Such  modules  may  constitute  only 
a  small  portion  of  the  total  program,  especially  where  the  program  is  large,  but  the  module 
may  nonetheless  contain  extremely  valuable  proprietary  technology.  It  is  recommended  that 
separable  modules  that  have  been  developed  at  private  expense,  and  are  incorporated  in 
deliverable  software,  be  treated  as  privately  developed  software.  To  protect  DoD’s  needs, 
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the  contracting  officer  should  have  the  flexibility  to  negotiate,  where  determined  necessary, 
for  greater  rights  (for  example,  program  restricted  rights)  in  privately  developed  modules,  or 
for  incorporation  of  only  those  modules  subject  to  at  least  government  purpose  rights. 

2.3.3.3.  How  should  rights  be  allocated  in  software  that  has  been  developed 
with  a  mix  of  government  and  private  resources? 

Private  and  public  sector  participants  at  the  Software  Rights  in  Data  Workshop  were  widely 
divided  over  what  should  be  the  appropriate  allocation  of  rights  in  mixed  funding  software. 
Both  agreed  that  negotiation  is  desirable  in  mixed  funding  situations,  and  that  the  govern¬ 
ment  should  have  certain  clearly  defined  minimum  rights  in  all  such  situations.  As  to  the 
extent  of  those  minimum  rights,  however,  there  was  considerable  disagreement. 

DoD  representatives  felt  that  something  close  to  unlimited  rights  would  be  useful  for  the 
government  to  achieve  competition  as  to  reprocurement,  and  maintenance  and  enhance¬ 
ment.  These  participants  felt  that  a  package  such  as  government  purpose  rights  might  be 
adequate  to  meet  DoD’s  needs  with  respect  to  competition,  but  could  be  administratively 
burdensome  since  the  government  might  then  have  to  monitor  use  of  the  software  by  a  third 
party. 

Industry  participants  advocated  a  set  of  rights  closer  to  the  four  minimum  rights  that  the 
government  obtains  in  restricted  rights  software.  They  felt,  however,  that  rights  to  disclose 
for  competitive  purposes  should  not  be  a  minimum  right  of  the  government  in  mixed  funding 
software  in  that  it  might  result  in  widespread  dissemination  of  their  software  technology. 

The  recent  revision  to  the  DoD  technical  data  regulations  adopted  government  purposes 
license  rights  as  the  set  of  rights  acquired  by  the  government  in  mixed  funding  situations. 
Under  this  set  of  rights  the  government  would  have  the  right  to  disseminate  software  and 
software  documentation  for  purposes  of  achieving  competition,  but  would  not  be  have  the 
right  to  permit  a  third  party  to  commercially  use  the  technology.  Although  the  revised 
DFARS  are  as  of  yet  untested,  this  type  of  approach  appears  to  hold  some  promise  of  strik¬ 
ing  a  reasonable  balance  between  the  respective  views  of  the  DoD  and  private  industry. 
The  government  would  obtain  sufficient  rights  to  fulfill  its  competitive  maintenance  and  en¬ 
hancement  needs,  while  contractors  would  be  protected  against  having  technology  they 
have  developed  being  generally  distributed.  The  benefit  to  the  government,  in  terms  of  in¬ 
creased  availability  of  quality  software,  would  seem  to  outweight  any  administrative  burden 
the  DoD  might  experience.  The  contracting  officer  should,  nonetheless,  have  the  authority 
to  negotiate  for  a  less  broad  set  of  rights,  such  as  rights  restricted  to  a  particular  program,  in 
those  situations  where  government  purpose  rights  would  not  be  necessary  to  meet  DoD’s 
needs. 

2.3.3.4.  When  is  software  "developed"  for  purposes  of  determining  if  it  has 
been  developed  at  private  expense? 

Another  important  issue  related  to  mixed  funding  is  ascertaining  when  software  is  developed 
for  purposes  of  determining  if  it  has  been  developed  at  private  expense.  This  definition 
determines  the  dividing  line  between  software  treated  as  developed  at  private  expense,  and 
that  which  will  be  treated  as  mixed  funding  software. 
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The  recent  revision  to  the  DoD  technical  data  regulations  defines  the  term  "developed"  as 
meaning  that  "the  item,  component,  or  process  exists  and  is  workable.  .  .  that  the  item  or 
component  has  been  constructed  or  the  process  practiced."  The  standard  set  forth  for  de¬ 
termining  "workability"  requires  that  the  "item,  component,  or  process  has  been  analyzed  or 
tested  sufficiently  to  demonstrate  to  reasonable  people  skilled  in  the  applicable  art  that  there 
is  a  high  probability  that  it  will  operate  as  intended"  [DFARS,  Sec.  227.471],  With  respect  to 
the  software  development  process,  it  appears  likely  that  such  a  standard  will  result  in  a  re¬ 
quirement  that  the  software  have  reached  the  testing  phase  in  its  life  cycle.  This  would 
generally  occur  somewhere  subsequent  to  implementation  or  writing  of  the  code,  but  prior  to 
deployment  or  reduction  to  practice. 

Discussions  at  the  Software  Rights  in  Data  Workshop  focused  on  whether  a  testing  require¬ 
ment  should  be  included  in  the  definition  of  the  term  "developed"  as  applied  to  software. 
Industry  participants  seemed  to  feel  that  such  a  requirement  did  not  reflect  the  technical 
realities  of  the  software  development  process.  Their  position  was  that  a  major  portion  of  the 
investment  in  a  software  product  occurs  prior  to  testing.  This  position  was  confirmed  by 
technical  participants  in  the  working  group.  The  DoD  participants  were  concerned,  however, 
that  by  accepting  less  than  unlimited  rights  in  software  in  which  the  DoD  currently  receives 
unlimited  rights,  the  government’s  ability  to  achieve  competition  for  software  maintenance 
and  enhancement  would  be  lessened. 

Significantly,  despite  the  differing  views  of  public  and  private  sector  participants,  a  com¬ 
promise  position,  in  the  form  of  a  proviso  to  be  appended  to  a  definition  of  the  term 
"developed"  proposed  by  the  DoD  participants,  was  drafted.  The  proviso  states  that  if  com¬ 
puter  software  exists,  and  no  significant  modifications  are  performed  in  order  to  satisfy  sub¬ 
sequent  applicable  tests  under  a  government  contract,  the  software  will  be  considered  to 
have  been  developed  at  private  expense.  With  the  addition  of  this  proviso,  the  full  text  of 
which  is  included,  along  with  government  and  industry  proposals,  in  Appendix  C,  the  indus¬ 
try  participants  were  willing  to  accept  the  government  view.  This  appears  to  be  a  realistic, 
workable  approach  to  defining  the  term  "developed"  for  purposes  of  determining  whether 
software  has  been  developed  at  private  expense  in  that  it  addresses  the  primary  concerns 
of  both  the  public  and  private  sector  participants. 

It  was  also  noted  at  the  workshop  that  an  adequate  mixed  funding  alternative  might  obviate 
the  importance  of  defining  the  term  "developed."  An  equitable  allocation  of  rights  in  soft¬ 
ware  developed  with  a  mix  of  public  and  private  funds  would  eliminate  the  harshness  of  the 
dichotomy  wherein  software  must  either  be  developed  exclusively  at  private  expense  or  be 
treated  as  though  developed  exclusively  at  public  expense. 

2.3.3.5.  Conclusion 

The  formulation  of  an  equitable  mixed  funding  policy  is  in  the  interests  of  both  the  DoD  and 
industry.  Government  purpose  license  rights  provide  the  DoD  sufficient  rights  to  meet  its 
needs,  while  allowing  industry  to  recoup  its  investment.  An  approach  that  treats  other  than 
slight  contributions  of  either  government  or  private  resources  as  mixed  funding  arrange¬ 
ments  appears  to  have  the  greatest  likelihood  of  providing  an  incentive  for  private  invest- 


CMU/SEI-87-TR-1 3 


June  1987 


21 


merit,  and  making  industry’s  most  innovative  ideas  available  to  the  DoD.  Separable  mod¬ 
ules,  developed  at  private  expense,  should,  however,  be  treated  as  having  been  privately 
developed. 
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3.  Conclusion 


The  DoD  needs  to  obtain  high  quality  software.  It  also  needs  to  be  able  to  use  and  support 
the  software  it  acquires,  and  to  achieve  competition  on  reprocurement.  Private  industry,  on 
the  other  hand,  needs  to  be  able  to  protect  its  proprietary  technology  and  commercialize  its 
products  in  order  to  recoup  its  investment  in  the  development  of  software,  including  software 
tools. 

The  DoD  data  rights  policy  has,  in  the  past,  been  imbalanced  in  the  direction  of  often  obtain¬ 
ing  more  rights  than  were  necessary  to  meet  its  mission  needs.  DoD’s  broad  claims  of 
rights  in  software  have  been  at  the  expense  of  losing  access  to  some  of  the  most  innovative 
technology  the  software  industry  has  to  offer.  The  DAR  Council  has,  at  the  urging  of  both 
the  Packard  Commission  and  Congress,  revised  its  policy  with  respect  to  acquiring  rights  in 
technical  data  so  as  to  provide  greater  balance  between  the  interests  of  the  DoD  and  indus¬ 
try.  A  new  policy  for  acquiring  rights  in  software  is  currently  under  consideration.  Because 
of  its  unique,  evolving  nature,  a  separate  policy  for  acquiring  rights  in  software  is  appro¬ 
priate. 

A  more  balanced  policy  for  acquiring  rights  in  software  developed  at  government  expense, 
software  developed  at  private  expense,  and  software  developed  with  mixed  funds  is  in  the 
interests  of  both  the  DoD  and  private  industry.  This  report  makes  several  recommendations 
for  achieving  a  balanced  policy  that  will  meet  the  mission  needs  of  the  DoD  while  enabling 
contractors  to  protect  their  proprietary  interests,  and  commercialize  their  software  products. 
Generally,  it  is  recommended  that  the  DoD  obtain  only  government  purpose  rights,  with  an 
option  to  acquire  unlimited  rights  where  needed,  in  government  funded  software;  restricted 
rights  in  privately  developed  software  and  related  documentation,  with  an  option  to  acquire 
less  than  the  minimum  restricted  rights  in  some  innovative  software  technology;  and  govern¬ 
ment  purpose  rights,  with  the  flexibility  to  negotiate  for  lesser  rights  where  sufficient  to  meet 
DoD’s  needs,  in  mixed  funding  software.  By  limiting  its  acquisition  of  rights  to  those  needed 
to  meet  its  mission  needs,  the  DoD  can  gain  access  to  the  innovative  software  technology  it 
needs,  and  provide  incentives  for  the  continuing  development  of  useful  software  products. 
In  this  way,  the  DoD  will  not  only  be  fostering  the  interests  of  both  industry  and  itself,  but 
also  those  of  the  nation. 
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Appendix  A:  Working  Group  A,  Intellectual  Property 
Requirements  for  Software  Maintenance  and 
Enhancement 

Issues 

OVERVIEW 

The  focus  of  this  working  group  is  to  define  an  appropriate  level  of  rights  in  software  that 
would  meet  DoD’s  software  maintenance  and  enhancement  needs  while  respecting  the 
proprietary  interests  of  industry.  Since  the  documentation  and  tools  needed  to  perform 
these  tasks  embody  material  which  may  be  proprietary  to  a  software  developer,  it  is  in  the 
maintenance  and  enhancement  context  where  many  of  the  most  critical  software  rights  is¬ 
sues  arise. 

In  addressing  this  complex  area,  the  working  group  may  wish  to  focus  on  the  following  is¬ 
sues: 

•  What  is  the  scope  of  rights  in  software  documentation  that  the  DoD  requires  in 
order  to  maintain  publicly  and  privately  developed  software? 

•  What  type  of  licensing  arrangements  will  enable  the  DoD  to  compete  contracts 
for  maintenance  and  enhancement? 

•  How  can  flexibility  be  built  into  a  software  rights  policy  to  reflect  variances  from 
acquisition  to  acquisition  in  DoD’s  needs  for  documentation  and  tools  to  main¬ 
tain  and  enhance  software? 

•  What  should  be  the  respective  rights  of  the  DoD  and  industry  in  software  that 
has  been  developed  at  public  expense  and  copyrighted  by  a  contractor? 

The  product  of  the  working  group  should  be  a  series  of  recommendations  reflecting  the 
group's  consensus  as  to  the  regulatory  treatment  of  each  of  the  four  primary  issues.  If  pos¬ 
sible,  a  rationale  for  each  recommendation  should  be  included.  If  consensus  cannot  be 
reached  on  a  particular  topic,  a  description  of  the  problems  as  to  why  the  group  could  not 
agree  should  be  provided.  Members  should  feel  free  to  submit  minority  position  statements. 

In  analyzing  these  issues,  the  group  may  find  it  useful  to  attempt  to  address  the  subissues 
set  forth  below.  Please  note  that  these  subissues  are  suggested  only  as  a  starting  point  and 
that  members  of  the  group  should  feel  free  to  formulate  their  own  approaches  to  addressing 
these  areas. 
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I.  WHAT  IS  THE  SCOPE  OF  RIGHTS  IN  SOFTWARE  DOCUMENTATION  THAT  THE 
DOD  NEEDS  TO  MAINTAIN  AND  ENHANCE  SOFTWARE? 

A.  SOFTWARE  DEVELOPED  AT  PUBLIC  EXPENSE 

1.  Does  the  DoD  always  need  unlimited  rights  to  maintain  and  enhance  software 
In-house? 

One  of  the  primary  reasons  for  DoD’s  broad  claim  of  unlimited  rights  in  publicly  funded  soft¬ 
ware  and  its  associated  documentation  is  to  enable  it  to  maintain  and  enhance  the  software 
both  in-house  or  through  private  firms  by  competitive  bidding.  Our  investigation  has 
revealed  that  there  is  a  strong  preference  within  the  DoD  for  organic  maintenance  of  soft¬ 
ware.  This  involves  performance  of  the  maintenance  function  by  government  personnel, 
sometimes  augmented  by  outside  support  contractors,  at  a  government  facility. 

Does  the  DoD  always  need  unlimited  rights  in  publicly  funded  software  and  its  documen¬ 
tation  to  enable  it  to  maintain  and  enhance  the  software  in-house? 

2.  Would  a  government  purpose  license  allow  the  DoD  to  maintain  and  enhance  Its 
software  In-house? 

It  has  been  argued  that  a  government  purpose  license  in  publicly  funded  software  is  suf¬ 
ficient  to  meet  DoD's  needs.  Such  a  license  could  be  defined  as  the  right  to  use,  duplicate, 
disclose,  distribute,  prepare  derivative  works  and  publicly  display  software  for  government 
purposes,  and  authorize  others  to  do  the  same  when  doing  so  would  fulfill  a  legitimate  gov¬ 
ernment  function. 

(a) .  If  the  DoD  were  to  obtain  a  government  purpose  license  in  publicly  funded  software 
and  its  documentation  in  lieu  of  unlimited  rights  would  this  allow  it  to  maintain  and  enhance 
such  software  in-house? 

(b) .  In  what  circumstances,  if  any,  would  such  a  license  not  allow  the  DoD  to  meet  its  main¬ 
tenance  and  enhancement  needs. 

3.  Does  the  DoD  need  a  derivative  works  right? 

An  important  issue  that  affects  DoD’s  rights  to  modify  and  enhance  software  developed  at 
public  expense  is  whether  the  DoD  has  the  right  to  prepare  derivative  software.  It  has  been 
argued  that  the  DoD  should  follow  the  example  of  the  Federal  Acquisition  Regulations  which 
includes  the  derivative  works  right  within  the  scope  unlimited  rights.  Some  DoD  personnel 
have  argued  that  an  explicit  derivative  works  right  is  unnecessary  since  it  is  implicit  in  the 
present  regulations. 

Should  DoD  regulations  include  a  derivative  works  right  within  unlimited  rights? 
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B.  SOFTWARE  DEVELOPED  AT  PRIVATE  EXPENSE 

I .  What  rights  does  the  DoD  need  to  perform  In-house  maintenance  and  enhance¬ 
ment  on  privately  developed  software? 

Under  the  current  regulatory  structure,  software  documentation  is  treated  as  technical  data. 
This  means  that  documentation  which  has  been  developed  at  private  expense  is  acquired 
by  the  DoO  with  limited  rights  (giving  the  government  the  right  to  use,  disclose  and  duplicate 
the  documentation  throughout  the  government).  Thus,  the  DoD  may  acquire  a  broader  set 
of  rights  in  documentation  for  non-commercial  restricted  rights  software  than  it  acquires  in 
the  software  itself.  This  is  true  even  though  the  restricted  rights  license  may  limit  use  of  the 
software  to  the  computer  for  which  or  with  which  it  was  acquired. 

(a) .  Does  the  DoD  need  rights  to  disclose  and  duplicate  the  documentation  throughout  the 
government  to  maintain  and  enhance  software  the  use  of  which  is  restricted  to  the  computer 
for  or  with  which  it  was  acquired  or  a  backup  computer? 

(b) .  What  rights  does  the  DoD  need  to  acquire  in  privately  developed  software  and  its  asso¬ 
ciated  documentation  to  enable  it  to  maintain  and  enhance  the  software  in-house? 

(c) .  Should  these  rights  be  different  for  privately  developed  commercial  software? 

II.  WHAT  TYPE  OF  LICENSING  ARRANGEMENTS  WILL  ENABLE  THE  DOD  TO  COM¬ 
PETE  CONTRACTS  FOR  MAINTENANCE  AND  ENHANCEMENT? 

A.  SOFTWARE  DEVELOPED  AT  PUBLIC  EXPENSE 

1.  What  Is  an  appropriate  means  of  competitively  maintaining  and  enhancing 
publicly  developed  software? 

Although  organic  maintenance  appears  to  be  the  preferred  method  of  maintaining  and  en¬ 
hancing  software,  the  DoD  will  sometimes  contract  all  or  a  portion  of  the  software  mainte¬ 
nance  and  enhancement  tasks  to  third  party  contractors  who  did  not  develop  the  software. 
The  Competition  in  Contracting  Act  (CICA)  requires  that  these  contracts  be  reopened  for 
competition  periodically,  unless  the  criteria  justifying  a  sole  source  procurement  are  met. 
The  requirement  to  competitively  procure  maintenance  services  is  one  of  the  primary 
rationales  for  DoD’s  broad-based  claim  of  unlimited  rights  in  software  and  its  documentation. 

(a) .  Does  the  current  set  of  unlimited  rights  provide  sufficient  rights  in  software  and  its  doc¬ 
umentation  to  enable  the  DoD  to  competitively  maintain  and  enhance  publicly  developed 
software? 

(b) .  Are  there  any  situations  in  which  the  DoD  may  not  need  to  acquire  unlimited  rights  in 
software  and  its  documentation  to  enable  it  to  competitively  maintain  software?  Please 
specify. 
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B.  SOFTWARE  DEVELOPED  AT  PRIVATE  EXPENSE 


1.  What  Is  an  appropriate  means  of  competitively  maintaining  and  enhancing 
restricted  rights  software? 

Under  the  current  regulatory  structure  the  DoD  has  experienced  difficulty  in  competitively 
maintaining  software  which  is  acquired  with  restricted  rights.  In  order  to  competitively  main¬ 
tain  such  software,  it  appears  that  the  DoD  would  need  to  negotiate  to  acquire  the  following 
rights  from  the  developing  contractor: 

(i)  the  ability  to  sublicense  its  software  modification  right  or  a 
commitment  by  the  contractor  to  license  another  company  to 
modify  the  software; 

(ii)  the  ability  to  sublicense  the  documentation  about  the  soft¬ 
ware,  or  a  commitment  by  the  contractor  to  license  the  other 
company  to  have  access  to  the  documentation; 

(iii)  very  detailed  documentation;  and  possibly 

(iv)  rights  in  the  software  tools,  or  a  commitment  from  the 
developing  firm  to  license  a  competitor’s  access  to  the  tools. 

a.  Under  what  circumstances  is  it  feasible  for  the  DoD  to  compete  the  mainte¬ 
nance  and  enhancement  of  privately  developed  software? 

b.  Should  a  software  rights  policy  provide  for  a  developing  contractor  to  agree  to 
enter  into  a  license  agreement  with  a  support  contractor  to  license  that  con¬ 
tractor  to  modify  the  software  and  to  have  access  to  documentation  and  tools 
needed  to  maintain  and  enhance  the  software?  How  would  such  a  provision 
be  structured? 

c.  Are  there  any  other  arrangements  that  could  be  made  to  enable  third  party 
support  contractors  to  maintain  and  enhance  privately  developed  software? 

III.  HOW  CAN  FLEXIBILITY  BE  BUILT  INTO  A  SOFTWARE  RIGHTS  POLICY  TO 
REFLECT  VARIANCES  FROM  ACQUISITION  TO  ACQUISITION  IN  DOD'S  NEEDS  FOR 
DOCUMENTATION  AND  TOOLS  TO  MAINTAIN  AND  ENHANCE  SOFTWARE? 

How  can  the  regulations  be  structured  to  allow  for  tailoring  to  more  accurately  reflect 
DoD’s  true  needs  with  respect  to  software  documentation  and  tools? 

There  is  increasing  recognition  within  the  DoD  of  the  importance  of  planning  early  in  acquisi¬ 
tion  process  for  the  maintenance  and  enhancement  of  software.  This  entails  the  early  iden¬ 
tification  of  the  documentation  and  tools  needed  to  support  software  as  well  as  the  intel¬ 
lectual  property  rights  needed  to  be  acquired  in  such  technology.  It  has  been  argued  that 
DoD’s  needs  for  certain  types  of  tools  and  documentation  and  the  rights  in  such  technology 
will  vary  from  acquisition  to  acquisition  in  accordance  with  several  variables.  This  creates  a 
window  of  opportunity  for  the  crafting  of  a  software  rights  policy  that  will  be  flexible  enough 
to  take  into  account  all  of  the  variables  affecting  DoD’s  needs  for  software  documentation 
and  tools. 
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A,  SOFTWARE  DOCUMENTATION 

1 .  Do  DoD’s  needs  for  documentation  to  maintain  and  enhance  software  vary  with: 

•  the  type  of  software  acquired?  (e.g.,  application  software,  operating  system 
software)? 

•  the  complexity  of  the  software? 

•  who  will  maintain  and  enhance  the  software? 

•  other  technical  variables? 

2.  Should  a  software  rights  policy  distinguish  among  different  types  of  documentation 
needed  for  maintenance  and  enhancement?  Please  specify. 

3.  How  can  a  software  rights  regulation  provide  flexibility  to  software  acquisition  personnel 
to  enable  them  to  structure  the  acquisition  to  obtain  only  the  documentation  critical  to  the 
maintenance  and  enhancement  of  the  particular  software  being  acquired? 

B.  SOFTWARE  TOOLS 

Throughout  our  field  research,  DoD  personnel  identified  access  to  various  software  tools  as 
vital  to  software  maintenance  and  enhancement.  However,  such  tools  are  often  among  the 
most  innovative  of  technological  developments  and  may  involve  substantial  private  invest¬ 
ment.  Developers  of  such  tools  are  often  reluctant  to  use  them  to  perform  DoD  contracts 
because  the  DoD  may  attempt  to  claim  rights  in  these  tools  under  the  current  standard  data 
rights  clause.  There  are  some  who  argue  that  the  present  policy  discourages  even  the  de¬ 
velopment  of  innovative  tools  because  of  these  proprietary  concerns. 

1 .  Do  DoD’s  needs  for  software  tools  to  maintain  and  enhance  software  vary  with: 

•  the  type  of  software  acquired? 

•  the  complexity  of  the  software  to  be  maintained? 

•  who  will  maintain  and  enhance  the  software? 

•  other  technical  variables? 

2.  Under  what  circumstances  does  the  DoD  require  access  to  a  developer’s  design  and 
development  tools  in  order  to  maintain  and  enhance  software  acquired  from  that  developer? 

3.  Is  it  possible  to  structure  a  provision  to  give  the  DoD  access  to  privately  developed  de¬ 
sign  and  development  tools  for  maintenance  and  enhancement? 

(a) .  Is  an  escrow  arrangement  allowing  the  government  access  upon  the  meeting  of  certain 
specified  conditions  feasible? 

(b) .  Is  providing  an  option  for  the  DoD  to  negotiate  to  take  less  than  the  minimum  restricted 
rights  in  proprietary  software  tools  feasible? 

4.  How  can  a  policy  be  structured  to  give  the  DoD  access  to  commercially  available 
proprietary  tools? 
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IV.  WHAT  SHOULD  BE  THE  RESPECTIVE  RIGHTS  OF  GOVERNMENT  AND  INDUSTRY 
IN  SOFTWARE  THAT  HAS  BEEN  DEVELOPED  AT  PUBLIC  EXPENSE  AND 
COPYRIGHTED  BY  THE  CONTRACTOR? 

1 .  What  should  be  the  policy  with  respect  to  copyrights  In  software? 

There  is  an  ambiguity  in  the  present  data  rights  regulations  concerning  the  extent  of  the 
government’s  rights  in  copyrighted  software  developed  at  public  expense.  One  part  of  the 
regulations  seems  to  give  the  DoD  unlimited  rights  in  such  software  because  it  was  devel¬ 
oped  at  public  expense  while  another  part  gives  the  government  only  government  purpose 
rights  if  the  contractor  decides  to  retain  a  copyright  in  the  software. 

It  appears  that  the  government  will  typically  not  know  the  extent  of  its  rights  until  the  soft¬ 
ware  is  delivered  to  the  government,  with  or  without  a  copyright  notice  attached.  This  could 
raise  some  complexities  with  respect  to  software  maintenance  and  enhancement  since 
modifications  of  software  are  derivative  works  that  may  qualify  for  copyright  protection. 

(a) .  Should  the  developing  contractor  be  required  to  give  notice  to  the  DoD  of  his  intent  to 
copyright  software  developed  at  public  expense? 

(b) .  Should  the  contractor  be  required  to  seek  permission  to  copyright  such  software? 
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Recommendations  of  Working  Group  A  on  Maintenance  Needs 

I.  AS  TO  PRIVATELY  DEVELOPED  SOFTWARE 

A.  The  set  of  things  the  government  will  ordinarily  acquire  for  itself 


1.  Software  &  standard  user  documentation 

The  government  will  normally  acquire  standard  user  documentation  along  with  object  code. 
Software  should  be  defined  to  include  such  standard  user  documentation  (as  well  as  code). 
The  government  should  get  the  same  standard  minimum  restricted  rights  in  both  object  code 
and  standard  user  documentation. 

2.  Source  code,  design  documentation,  tools,  and  other  things  necessary  to  support 
software. 

The  government  ordinarily  does  not  need  to  take  delivery  of  source  code  and  other  support 
materials  for  commercially  available  (with  some  specific  exceptions)  software.  It  may  need 
the  option  to  acquire  rights  in  such  materials  when  it  desires  to  perform  a  support  function 
internally.  In  general,  an  important  advantage  to  the  government  in  acquiring  privately  de¬ 
veloped  software  is  not  having  to  perform  support  functions  for  it. 

r 

B.  The  need  to  have  assurance  of  adequate  support  for  the  software 

A  major  concern  of  the  government  is  to  be  able  to  have  assurance  that  software  developed 
at  private  expense  can  adequately  be  supported  either  by  the  original  developer  or  by  a 
responsible  third  party. 

To  achieve  a  balance  between  the  government’s  needs  to  be  assured  of  adequate  support 
and  industry’s  need  for  proprietary  protection,  the  group  recommends  that  a  conditional  di¬ 
rected  licensing  clause  be  developed  as  an  option  to  be  included  in  government  contracts, 
which  would  include  an  escrow  of  support  material.  (It  would  be  a  variation  on  an  existing 
DOE  clause,  but  tailored  as  described  below.) 

The  basic  principle  of  such  a  clause  would  be  an  agreement  that  the  original  developer 
would  agree  to  license  the  software  and  escrowed  material  to  a  responsible  third  party  to 
perform  support  functions  if  the  original  developer  was  unwilling  or  unable  to  do  so.  There 
was  disagreement  within  the  group  about  whether  the  government  should  perform  support 
functions  in  place  of  a  responsible  third  party. 
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1.  Triggering  mechanism 

There  would  be  a  provision  that  the  government  can  notify  a  contractor  that  if 
the  contractor  is  unwilling  or  unable  to  perform  support  functions  for  the  soft¬ 
ware  in  a  reasonable  manner,  and  at  a  reasonable  price,  the  government  will 
invoke  its  rights  to  transfer  the  support  functions  to  a  third  party,  and  the  li¬ 
cense  will  implicitly  be  granted  to  that  third  party  to  perform  the  support  func¬ 
tions. 

2.  The  scope  of  the  third  party’s  rights 

The  third  party  will  only  have  the  scope  of  rights  in  the  software  necessary  for 
support  of  the  software  within  the  scope  of  the  original  contract  that  the  gov¬ 
ernment  had.  As  to  the  support  documentation  that  will  be  released  from 
escrow,  the  third  party  will  be  able  to  use  it  only  for  purposes  of  supporting  the 
software  for  the  government  in  accordance  with  the  scope  of  the  original  con¬ 
tract.  The  original  contractor  will  have  the  rights  to  sue  the  third  party  directly 
under  the  license  if  the  third  party  abuses  the  license  to  the  disadvantage  of 
the  contractor. 

3.  Technical  assistance 

To  be  able  to  support  the  software,  the  third  party  will  often  need  technical 
assistance  from  the  original  developer.  The  directed  licensing  clause  should 
obligate  the  contractor  to  provide  technical  assistance  to  the  third  party. 

4.  Escrow  for  documentation  &  tools 

(a) .  What  to  escrow 

All  materials  that  are  needed  to  regenerate  or  modify  the  software  and 
that  were  not  delivered  to  the  government  under  the  original  contract 
should  be  placed  in  escrow  so  that  if  the  contractor  is  unwilling  or 
unable  to  perform  support  functions,  the  government  will  be  able  to  obtain 
the  support  materials  either  for  itself  or  for  a  responsible  third  party 
maintainer. 

Among  the  software  materials  that  may  be  needed  for  regeneration  and 
modification  are  software  elements  such  as  source  code,  relocatable  object 
code,  and  system/linker  directives,  executable  load  image  and  software 
documentation,  such  as  flow  charts,  design  specifications,  and 
implementation  specifications.  Tools  may  also  be  escrowed. 

(b) .  Escrow  agent 

There  was  consensus  that  an  agent  acceptable  to  both  parties  would  be 
needed  to  act  as  escrow  agent.  Both  sides  need  adequate  protection  that 
the  escrow  is  bonafide.  The  escrow  agent  should  be  selected  accordingly. 

(c) .  When  to  escrow 

All  such  support  materials  should  be  placed  in  escrow  at  the  time  the 
object  code  is  delivered  to  the  government.  Whenever  updates  within  the 
scope  of  the  original  contract  are  issued,  the  escrow  agent 
should  receive  updated  documentation  to  reflect  changes  in  the  code. 

The  source  code  should  be  certified  when  placed  in  escrow. 
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(d) .  Circumstances  under  which  the  government  could  obtain  release 

of  the  escrowed  materials 

When  the  contractor  is  unwilling  or  unable  to  continue  to  perform  support 
for  software,  the  contractor  may  be  willing  to  notify  the  escrow  agent  to 
have  the  escrowed  material  released  to  the  responsible  third  party 
maintainer.  If  the  contractor  contests  the  government’s  claim  that  the 
contractor  is  not  supporting  the  software  in  a  reasonable  manner 
(or  whatever),  it  will  take  a  finding  by  the  head  of  the  government 
agency  that  the  government  has  a  valid  claim  to  get  escrowed  materials 
released  to  the  third  party  maintainer.  The  contractor  shall  be  notified 
of  the  release  from  escrow,  to  whom  the  escrowed  material  has  been  given, 
and  who  the  third  party  maintainer  is,  and  instructed  to  negotiate 
transition  assistance  with  the  third  party. 

(e) .  Damages  for  improper  release  from  escrow 

If  litigation  later  reveals  that  the  government  did  not  meet  the  standard 
to  get  the  materials  released  from  escrow,  the  government  will  be  liable 
for  necessary  damages  for  improper  release.  The  group  differentiated  this 
situation  from  the  validation  challenge  procedure  because  even  when 
released  from  escrow,  the  support  materials  will  be  subject  to 
restrictions  on  the  third  party’s  use,  and  will  not  be  distributed  to 
the  public  the  way  that  technical  data  whose  restrictive  legends  have 
been  removed  would  be. 

(f) .  Directed  license  vs.  sublicense 

The  group  recommends  that  the  government  adopt  a  directed  license  approach 
instead  of  a  sublicense  so  that  disputes  between  the  original  contractor 
and  the  third  party  can  be  fought  without  direct  government  involvement. 

The  protection  for  the  government  comes  from  the  fact  that  the  contractor 
will  have  agreed  upfront  to  license  a  responsible  third  party  to  perform 
support  functions  if  the  is  unable  or  unwilling  to  do  so,  and  once  a 
finding  has  been  made  by  the  head  of  the  agency  that  the  standard 
for  escrow  release  has  been  achieved,  a  license  will  be  deemed  to  have 
been  granted  by  the  developer  to  the  third  party.  The  government 
may  have  little  need  to  invoke  the  rights  under  the  directed 
licensing  provision  because  the  power  to  invoke  the  third  party  license 
creates  a  powerful  incentive  for  the  contractor  to  seek  a  more  consensual 
arrangement. 

(g) .  Software  documentation  for  software  that  isn’t  commercially 

available 

Documentation  for  software  that  is  not  commercially  available  may  be  more 
sparse  or  incomplete  than  documentation  for  commercial  software.  The 
government  may  sometimes  need  to  pay  for  the  creation  of  additional 
documentation  for  the  software  it  will  need  to  support  the  system. 
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II.  AS  TO  GOVERNMENT  FUNDED  SOFTWARE 


A.  Completely  funded  by  the  government 

1.  Set  of  rights  in  the  government 

(a) .  Unlimited  rights  vs  government  purpose  rights 

In  order  to  maintain  and  enhance  software,  the  government  may  not  need  the 
broad  set  of  rights  that  the  present  unlimited  rights  policy  provides. 

Government  purpose  rights  may  adequately  protect  the  government’s  interest 
so  long  as  the  government  is  able  to  compete  for  maintenance  services. 

However,  the  broad  unlimited  rights  policy  does  have  an  economic  value 
for  the  government  which  the  government  may  wish  to  preserve  unless  given 
an  incentive  to  relinquish  this  (e.g.,  a  lower  price  for  the  development 
contract  or  other  compensation). 

(b) .  The  degree  of  flexibility  for  contract  officers 

There  was  consensus  that  contract  officers  should  have  flexibility  to 
negotiate  for  less  than  unlimited  rights  (for  example,  rights  restricted 
to  a  particular  agency  or  project)  in  order  to  achieve  other  goals  in  a 
software  development  competition. 

Industry  may  have  more  incentives  to  achieve  broader  technology  transition 
than  the  government.  It  may  be  in  the  government’s  broader  interest  for 
this  technology  transition  to  occur.  It  may  be  necessary  for  the  government 
to  relinquish  its  broad  rights  (which  include  the  power  to  put  trade 
secrets  which  confer  a  commercial  advantage  to  the  contractor  in  the 
public  domain)  and  to  allow  enough  exclusivity  to  create  incentives  to 
commercialize  the  software. 

(c) .  Definition  of  unlimited  and  government  purpose  rights 

The  government  shall  have  the  rights  to  use  duplicate,  disclose, 
distribute,  modify,  &  make  derivative  works  of  software  developed 
wholly  at  government  expense  and  to  have  or  permit  others  to  do  so. 

These  are  unlimited  rights.  When  the  government  negotiates  for 
government  purpose  rights,  the  same  set  of  terms  applies  except  that 
they  are  limited  to  government  purposes. 

2.  The  government’s  interest  in  competing  maintenance  &  enhancement  for  publicly  funded 

software. 

(a).  Policy  statement 

There  exist  situations  when  the  government  may  benefit  by  acquiring  less 
than  unlimited  rights  in  software.  To  accommodate  this  situation,  there 
should  be  flexibility  to  conduct  limited  competition,  rather  than  full  and 
open  competition,  in  the  procurement  of  software  maintenance  and 
enhancement  services. 
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(b).  Rationale 

This  option  allows  the  government  to  achieve  the  benefits  of  competition  for 
software  enhancement  and  maintenance. 

It  also  permits  protection  for  the  software  developer’s  proprietary 
information  in  which  the  government  has  rights  by  distributing  it  only  to 
limited  set  of  bidders  (with  appropriate  safeguards)  rather  than  to  the 
public  at  large. 

3.  Subsequent  commercialization  of  software  developed  at  public  expense 

If  the  government  takes  less  than  unlimited  rights,  and  the  contractor  derives  additional 
revenue  from  that  or  derivative  products,  there  should  be  flexibility  for  the  government  to 
negotiate  to  receive  benefits  from  subsequent  commercial  sales. 

4.  Documentation  as  to  software  developed  at  government  expense 

The  government  will  acquire  such  documentation  in  software  developed  at  public  expense 
as  is  necessary  to  comply  with  requirements  of  the  DoD  standard  2167  or  other  appropriate 
government  standards.  The  government  will  acquire  normally  the  same  rights  in  the  docu¬ 
mentation  as  the  software. 

5.  Tools  developed  at  private  expense  used  in  performance  of  contract 

The  government  or  its  contractors  need  possession  of  the  tools  that  are  required  for  the 
purpose  of  use  in  life  cycle  maintenance  and/or  enhancement  of  the  deliverable  software. 

The  government  should  obtain  a  license  that  is  restricted  to  this  need  and  adequately 
protects  the  tool  developer’s  proprietary  intellectual  property  rights. 

6.  Tools  or  software  components  developed  at  private  expense  during  the  performance  of 
contract  and  used  in  the  development  of  government  funded  software 

If  required  to  support  the  software,  tools  or  software  components  developed  at  private  ex¬ 
pense  during  performance  of  the  contract  and  used  to  develop  government  funded  software 
should  be  treated  the  same  as  if  the  tools  were  preexisting  privately  developed  tools. 

7.  Tools  or  software  components  proposed  to  be  developed  at  government  expense  which 
can  be  used  in  developing  government  funded  deliverable  software 

Contract  officers  should  have  the  flexibility  to  negotiate  to  acquire  less  than  unlimited  rights 
in  innovative  alternative  tools  or  software  components  that  are  not  already  required  to  be 
delivered  under  the  contract,  but  that  are  proposed  to  be  developed  during  the  performance 
of  the  contract. 
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Appendix  B:  Working  Group  B,  The  Scope  of  a 
Software  Rights  Policy 

Issues 

OVERVIEW 


The  focus  of  this  working  group  is  to  examine  the  scope  of  coverage  of  a  new  software 
rights  policy.  This  entails  an  evaluation  of  the  rationales  underlying  the  current  policies  for 
publicly  and  privately  developed  software,  and  a  determination  as  to  the  extent  to  which  they 
are  meeting  DoD’s  needs. 

In  addressing  this  topic,  the  group  may  wish  to  focus  on  the  following  issues: 

•  Does  the  DoD  always  need  unlimited  rights  in  publicly  funded  software? 

•  What  set  of  minimum  rights  does  the  DoD  need  in  software  that  has  been  de¬ 
veloped  at  private  expense? 

•  How  broad  should  the  software  rights  policy  be? 

The  product  of  the  working  group  should  be  a  series  of  recommendations  reflecting  the 
group’s  consensus  as  to  the  regulatory  treatment  of  each  of  the  three  primary  issues.  If 
possible,  a  rationale  for  each  recommendation  should  be  included.  If  consensus  cannot  be 
reached  on  a  particular  topic,  a  description  of  the  problems  as  to  why  the  group  could  not 
agree  should  be  provided.  Members  should  feel  free  to  submit  minority  position  statements. 

In  analyzing  these  issues,  the  group  may  find  it  useful  to  attempt  to  address  the  subissues 
set  forth  below.  Please  note  that  these  subissues  are  suggested  only  as  a  starting  point  and 
that  members  of  the  group  should  feel  free  to  formulate  their  own  approaches  to  addressing 
these  areas. 

I.  DOES  THE  DOD  ALWAYS  NEED  UNLIMITED  RIGHTS  IN  PUBLICLY  FUNDED 
SOFTWARE? 

1 .  Does  the  DoD  need  to  claim  unlimited  rights  In  a  broad  spectrum  of  software  and 
documentation? 

The  DoD  currently  claims  unlimited  rights  in  a  broad  spectrum  of  software  developed  at 
public  expense.  This  includes: 

(i)  software  and  documentation  resulting  directly  from  performance 
of  experimental,  developmental  or  research  work  specified 

in  a  government  contract. 

(ii)  software  and  documentation  required  to  be  originated  or 
developed  under  government  contract  or  generated  as  a 
necessary  part  of  performing  a  contract. 
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(iii)  software  and  documentation  constituting  corrections  or 
changes  to  government  furnished  software. 

(iv)  manuals  or  instructional  materials  prepared  or  required 
to  be  delivered  under  government  contract  for  in¬ 
stallation,  operation,  maintenance  or  training  purpose. 

(a) .  Does  the  DoD  actually  need  to  acquire  unlimited  rights  in  all  these  categories  of  soft¬ 
ware? 

(b) .  Is  it  appropriate  for  the  DoD  to  claim  unlimited  rights  in  instructional  materials  or 
manuals  for  software  that  has  been  developed  at  private  expense  and  acquired  with 
restricted  rights? 

2.  Would  a  government  purpose  license  In  publicly  developed  software  allow  the 
DoD  to  satisfy  Its  needs? 

It  has  been  argued  that  the  acquisition  by  the  DoD  of  a  government  purpose  license  in 
publicly  funded  software  would  enable  the  DoD  to  meet  its  needs.  In  this  context,  a  govern¬ 
ment  purpose  license  is  defined  as: 

a  license  to  the  federal  government  that  grants  the  government  rights  to  use,  du¬ 
plicate,  disclose,  distribute,  prepare  derivative  works,  and  publicly  display  software 
for  government  purposes,  and  to  authorize  others  to  exercise  such  rights  when 
doing  so  will  fulfill  a  legitimate  federal  governmental  function. 

(a) .  Would  a  government  purpose  license  allow  the  DoD  to  meet  its  needs? 

(b) .  Assuming  a  government  purpose  license  for  publicly  developed  software  would  meet 
DoD's  needs  in  at  least  some  instances,  are  there  any  revisions  which  should  be  made  to 
the  definition  noted  above? 

(c) .  Would  government  purpose  rights  in  software  and  its  documentation  satisfy  industry’s 
concerns? 

(d) .  Are  there  any  circumstances  under  which  the  DoD  might  need  broader  unlimited  rights 
as  opposed  to  government  purpose  rights  in  publicly  developed  software  and  its  documen¬ 
tation?  What  are  those  circumstances? 

3.  What  are  appropriate  policy  goals  for  the  DoD  In  acquiring  rights  In  software  de¬ 
veloped  at  public  expense? 

Developing  a  policy  for  publicly  developed  software  requires  a  reevaluation  of  DoD’s  prior¬ 
ities.  The  DoD  currently  claims  unlimited  rights  in  a  broad  spectrum  of  software  and  tech¬ 
nical  data  which  has  been  developed  at  public  expense.  The  concept  of  giving  the  DoD  the 
right  to  use,  duplicate  or  disclose  in  any  manner  and  for  any  purpose  whatsoever  stems 
from  longstanding  policy  that  when  the  government  pays  for  research  and  development  that 
produces  new  knowledge,  products  or  processes,  it  has  an  obligation  to  foster  progress 
through  a  wide  dissemination  of  the  new  technology.  Other  rationales  for  claiming  unlimited 
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rights  in  software  developed  at  public  expense  include  performance  of  maintenance  and  en¬ 
hancement  and  competitive  reprocurement.  It  has  been  argued  that  DoD’s  broad  claim  of 
unlimited  rights  deters  high  tech  firms  from  licensing  their  most  innovative  technology  to  the 
DoD.  In  light  of  this,  it  may  be  appropriate  to  re-examine  DoD’s  priorities  to  ascertain 
whether  the  unlimited  rights  concept  is  allowing  the  DoD  to  meet  its  needs. 

What  are  the  appropriate  goals  that  would  justify  the  DoD  acquiring  unlimited  rights  in  soft¬ 
ware  developed  at  public  expense? 

•  Dissemination  of  new  technology? 

•  Performance  of  maintenance  and  enhancement? 

•  Competitive  reprocurement? 

•  Others? 

4.  Should  the  contractor  who  develops  software  for  the  DoD  at  public  expense  retain 
any  rights  In  the  software  and  Its  documentation? 

In  the  course  of  our  research,  several  questions  were  raised  as  to  what  rights,  if  any,  con¬ 
tractors  should  retain  in  software  that  has  been  developed  with  public  funds. 

(a) .  Should  the  contractor  retain  the  right  to  commercialize  software  developed  at  public 
expense? 

(b) .  If  the  contractor  were  to  prepare  derivatives  of  the  software  delivered  to  the  DoD,  for 
his  own  internal  use  or  for  marketing,  should  the  DoD  have  any  rights  to  these  derivatives? 
Why? 

(c) .  Are  there  any  other  rights  which  it  might  be  appropriate  for  a  contractor  to  retain  in 
software  developed  at  public  expense? 

(d) .  Assuming  it  is  appropriate  for  the  contractor  to  retain  some  rights  in  software  and  docu¬ 
mentation  developed  at  public  expense,  should  a  software  rights  clause  set  forth  those 
rights? 

II.  WHAT  SET  OF  MINIMUM  RIGHTS  DOES  DOD  THE  NEED  IN  SOFTWARE  THAT  HAS 
BEEN  DEVELOPED  AT  PRIVATE  EXPENSE? 

1 .  Is  there  a  set  of  minimum  rights  that  the  DoD  will  always  need  to  obtain? 

The  current  regulations  provide  that  software  which  has  been  developed  at  private  expense 
is  acquired  by  the  DoD  with  restricted  rights,  which  include  as  a  minimum  the  right  to: 

(i)  Use  the  software  with  the  computer  for  which  or  with  which 
it  was  acquired,  including  any  government  facility  to  which 
it  may  be  transferred; 

(ii)  Use  the  software  with  a  backup  computer  if  the  computer  for 
which  or  with  which  it  was  acquired  is  inoperative; 
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(iii)  Copy  programs  for  safekeeping;  and 

(iv)  Modify  computer  software,  or  combine  it  with  other  software 
"subject  to  the  provision  that  those  portions  of  the 
derivative  software  incorporating  restricted  rights  software 
are  subject  to  the  same  restricted  rights". 

Additionally,  restricted  rights  include  any  other  rights  which  are  not  inconsistent  with  the 
above  minimum  rights  which  are  listed  in  the  software  contract  or  in  a  license. 

(a) .  Does  the  current  set  of  restricted  rights  meet  the  DoD’s  needs? 

(b) .  Should  the  DoD  have  the  right  to  disclose  or  reproduce  privately  developed  software 
for  use  by  support  contractors  (contractors  who  maintain  and  enhance  the  software)  subject 
to  their  "agreement  to  abide  by  the  other  restrictions  that  bind  the  DoD  in  its  use  of  the 
software"? 

(c) .  Should  the  DoD  have  the  right  to  reverse  engineer  software  that  has  been  developed  at 
private  expense  in  order  to  make  modifications? 

(d) .  Should  there  continue  to  be  a  different  set  of  minimum  restricted  rights  for  privately 
developed  commercial  software? 

2.  Would  It  be  In  DoD’s  best  Interests  to  be  able  to  acquire  less  than  minimum  rights 
In  certain  Innovative  technologies? 

Several  studies  have  pointed  out  that  the  DoD  may  not  be  getting  access  to  some  of  the 
most  innovative  software  technology  such  as  tools  and  CAD/CAM  programs  because  of  its 
current  software  and  data  rights  policy.  Because  of  the  potential  commercial  value  of  such 
technology,  its  developers  are  reluctant  to  expose  it  to  the  risk  that  the  DoD  may  disclose  it 
to  their  competitors.  It  has  been  suggested  that  a  means  of  accessing  such  technology 
might  be  through  providing  the  DoD  with  a  limited  license  which  provides  the  DoD  less  than 
the  minimum  restricted  rights,  for  example  providing  electronic  access  to  a  CAD/CAM  pro¬ 
gram.  Other  alternatives  include  use  of  an  escrow  arrangement  for  software  tools. 

(a) .  Is  it  feasible  to  provide  an  option  for  the  DoD  to  negotiate  to  take  less  than  the  mini¬ 
mum  restricted  rights  in  certain  types  of  privately  developed  software  technology?  How 
might  such  an  arrangement  be  structured? 

(b) .  Is  an  escrow  arrangement  allowing  the  DoD  access  to  software  technology  upon  the 
meeting  of  certain  specified  conditions  feasible? 

(c) .  Is  it  feasible  to  provide  for  an  arrangement  whereby  a  tool  developer  would  directly 
license  his  tool  to  a  support  contractor  designated  by  the  DoD  to  do  DoD  work? 

(d)  Would  it  be  feasible  to  provide  the  DoD  with  an  option  to  acquire  certain  tools  or  other 
technology?  How  would  such  an  option  be  structured? 
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III.  HOW  BROAD  SHOULD  THE  SOFTWARE  RIGHTS  POLICY  BE? 


1 .  What  should  be  Included  within  the  scope  of  the  software  rights  policy? 

Different  views  have  been  expressed  as  to  what  should  be  included  within  the  scope  of  a 
software  rights  policy,  especially  with  respect  to  software  documentation.  Some  types  of 
software  documentation  are  more  critical  than  the  others  in  making  effective  use  of  a  soft¬ 
ware  product  for  the  purpose  for  which  it  was  acquired.  Other  issues  arise  due  to  the 
unique  nature  and  capabilities  of  software. 

(a) .  Should  some  types  of  software  documentation  be  treated  as  software?  Please  specify. 

(b) .  How  can  flexibility  be  built  into  the  regulation  to  reflect  the  variances  in  DoD’s  need  for 
documentation  while  at  the  same  time  protecting  the  private  sector’s  interests? 

(c) .  Should  there  be  a  specific  policy  with  respect  to  acquisition  of  rights  in  local  area  net¬ 
works  (LANS)? 

(d) .  Should  semiconductor  chips  be  included  within  the  software  rights  policy? 

(e) .  Should  there  be  a  specific  policy  with  respect  to  "worms"  or  "time  bombs"? 

(f) .  How  should  software  data  bases  be  treated? 
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Working  Group  B:  Draft  Recommendations 

Issue  I:  What  are  appropriate  policy  goals  for  the  DoD  in  acquiring  rights  in  publicly  funded 
software? 

Recommendation:  Appropriate  policy  goals  include  (1 )  performance  of  maintenance  and 
enhancement,  (2)  competitive  reprocurement,  and  (3)  reuse. 

Rationale:  Although  there  are  some  instances  where  dissemination  of  new  software  tech¬ 
nology  may  be  an  appropriate  policy  goal  for  purposes  of  promoting  commercial  develop¬ 
ment  or  otherwise,  the  DoD  does  not  need  the  right  to  disseminate  software  technology  in 
all  cases.  With  respect  to  commercialization,  the  original  developer  is  generally  in  the  best 
position  to  commercialize  software  technology  because  of  its  base  knowledge  and  experi¬ 
ence  in  developing  the  product. 

Issue  II:  Does  the  DoD  always  need  unlimited  rights  in  publicly  funded  software,  or  would  a 
government  purpose  license  in  such  software  allow  the  DoD  to  satisfy  its  goals? 

Recommendation:  DoD’s  objectives  as  stated  above  can  be  achieved  by  the  DoD  acquir¬ 
ing  less  than  unlimited  rights  in  software  developed  at  public  expense.  (Unlimited  rights  are 
themselves  not  equivalent  to  ownership.)  It  therefore  does  not  appear  that  the  DoD  neces¬ 
sarily  needs  broad  unlimited  rights  in  every  category  of  software. 

Normally,  software  which  has  been  funded  even  with  100%  government  funds  under  gov¬ 
ernment  contract  should  be  procured  under  a  license  restricting  the  government  to  the  rights 
to  copy,  disclose,  enhance,  maintain,  modify,  prepare  derivative  works,  or  otherwise  use  the 
software  for  government  purposes.  "Government  purposes"  will  ordinarily  exclude  any  ac¬ 
tion,  including  unrestricted  public  dissemination,  that  will  detract  from  the  commercial  value 
of  the  software  to  the  developer.  In  implementing  this  recommendation  for  restricted  gov¬ 
ernment  purpose  licenses  in  publicly  funded  software,  consideration  might  be  given  to 
mechanisms  for  contract  price  reductions,  royalties,  and/or  time  limitations  for  restrictions  on 
dissemination. 

Rationale:  As  noted  above,  the  developer  is  often  in  the  best  position  to  commercialize  the 
software,  but  acquisition  of  unlimited  rights  by  the  DoD,  which  includes  a  substantial  risk  of 
unrestricted  disclosure  to  competitors,  may  reduce  the  incentive  of  the  software  developer  to 
pursue  such  commercial  development.  A  government  purpose  license  would  ordinarily  al¬ 
low  the  DoD  to  meet  its  own  needs,  provided  that  the  developer  agrees  to  permit  use  for 
maintenance,  enhancement,  or  competitive  procurement  by  third  parties  who  have  in  turn 
agreed  not  to  use  the  software  commercially  without  prior  written  authorization  of  the  devel¬ 
oper.  Thus,  it  was  not  the  intent  of  this  recommendation  to  preclude  disclosure  to  third 
parties  for  government  purposes  so  long  as  such  third  parties  have  accepted  an  obligation 
not  to  use  the  software  for  commercial  purposes.  That  obligation  might  best  be  enforced  by 
use  of  associate  restricted  use  and  non-disclosure  licenses  between  the  developer  and  sup¬ 
port  contractors,  subsequent  bidders,  etc.  In  some  instances,  copyright  infringement  actions 
for  breach  of  a  copyright  license  may  be  sufficient. 
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Issue  III:  What  set  of  minimum  rights  does  the  DoD  need  in  software  that  has  been  devel¬ 
oped  at  private  expense? 

Recommendations: 

a.  The  existing  set  of  minimum  restricted  rights  generally  meets  DoD’s  needs. 

The  DoD,  however,  should  also  have  the  right  to  use  software  with  an  up¬ 
wardly  compatible  replacement  computer  in  cases  where  the  software  is  li¬ 
censed  alone  instead  of  as  part  of  a  system. 

b.  The  group  was  split  over  whether  the  DoD  should  have  the  right  to  disclose 
software  for  use  by  support  contractors  without  a  required  condition  that  sup¬ 
port  contractors  sign  a  non-disclosure  and  non-use  agreement  with  the  orig¬ 
inal  developer  or  be  bound  by  an  organizational  conflict  of  interest  clause  in 
the  support  contractor’s  contract  with  the  government. 

c.  The  DoD  does  not  need  to  have  the  right  to  reverse  engineer  software  in¬ 
cluded  in  the  set  of  minimum  rights. 

d.  There  should  not  be  a  set  of  restricted  rights  applicable  to  privately  developed 
commercial  software  that  is  different  from  the  set  of  minimum  rights  applicable 
to  privately  developed  non-commercial  software. 


Rationales: 

a.  The  existing  minimum  rights  generally  permit  use  of  software  by  the  DoD  that 
is  sufficient  for  DoD’s  purposes.  The  only  exception  is  DoD’s  need  to  be  able 
to  transfer  old  software  to  replacement  hardware  that  will  accept  it  without 
rehosting. 

b.  Industry  wants  either  a  right  to  protect  its  privately  developed  software  itself  or 
have  assurance  that  any  support  contractor  be  limited  to  a  support  role  only 
for  its  use  of  such  privately  developed  software.  Some  government  represen¬ 
tatives  present  did  not  disagree  with  industry’s  objectives  but  they  were  not  in 
agreement  with  imposing  such  requirements  in  the  body  of  a  software  policy 
or  regulation.  They  felt  such  a  regulatory  requirement  could  pose  an  adminis¬ 
trative  burden.  They  also  did  not  believe  that  requiring  insertion  of  an  or¬ 
ganizational  conflict  of  interest  clause  was  properly  part  of  the  software  ac¬ 
quisition  process. 

c.  -  d.  These  recommendations  are  self-explanatory. 

Issue  IV:  Would  it  be  in  DoD’s  best  interests  to  be  able  to  acquire  less  than  minimum  rights 
in  certain  innovative  technologies? 

Recommendation:  There  should  be  some  flexibility  built  into  the  regulation  to  allow  the 
DoD  to  negotiate  to  take  less  than  the  four  minimum  restricted  rights  in  privately  developed 
software  where  appropriate. 

Rationale:  All  recognized  that  some  innovative  technologies  beneficial  to  the  government 
can  likely  only  be  acquired  with  less  than  the  existing  minimum  restricted  rights.  The  group 
differed  over  an  appropriate  method  of  injecting  flexibility  into  the  regulation.  Some  felt  that 
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the  current  practice  of  requiring  a  DAR  deviation  was  not  unduly  restrictive  and  should  be 
retained,  on  the  theory  that  minimum  government  rights  should  not  be  too  easily  waived  by 
contracting  officers.  Others  felt  that,  because  the  DAR  deviation  process  was  too  cumber¬ 
some  and  time  consuming,  an  intra-agency  approval  process  would  be  more  appropriate. 

Issue  V:  How  broad  should  the  software  rights  policy  be? 

Recommendations: 

a.  Software  documentation  generally  should  be  treated  in  the  same  manner  as 
the  related  software.  However,  user  manuals  which  do  not  include  source 
code,  algorithms,  processes,  formulae,  or  flow  charts  should  be  acquired  by 
the  DoD  with  a  broad  government  purpose  license,  even  where  the  related 
software  is  acquired  under  more  restrictive  rights. 

b.  A  software  rights  policy  should  provide  some  broad  guidance  similar  to  that 
contained  in  the  FAR  to  procurement  personnel  to  consider  possible  LAN  use 
when  negotiating  acquisition  of  privately  developed  software. 

c.  Software  embedded  in  semiconductor  chips  or  other  devices  should  be  in¬ 
cluded  within  the  scope  of  the  software  rights  policy. 

d.  The  government  should  be  informed  of  the  existence  of  triggers,  worms  and 
time  bombs  designed  into  software  delivered  to  the  government. 

e.  Technical  data  should  be  governed  by  the  technical  data  rights  policy  regard¬ 
less  of  the  medium  in  which  the  data  is  delivered  or  stored. 

Rationales: 

a.  User  manuals,  which  need  not  include  source  code,  algorithms,  processes, 
formulae,  or  flow  charts  to  meet  their  intended  purposes,  need  to  be  broadly 
and  easily  disseminated  for  instructional  use.  Moreover,  because  of  the  way 
user  manuals  are  utilized,  the  government  would  have  difficulty  policing  a 
more  restrictive  license  regarding  such  manuals. 

b.  Existing  computer-restricted  rights  may  not  adequately  provide  for  LAN  use. 

c.  Software  is  software  regardless  of  the  medium  in  which  embedded. 

d.  This  recommendation  is  self-explanatory. 

e.  Data,  acquired  under  the  technical  data  rights  policy,  should  be  distinguished 
from  the  data  base  management  system  which  actually  manipulates  the  data. 

The  data  base  management  system  is  software  and  should  be  acquired  under 
the  software  rights  policy.  There  are,  however,  instances  where  it  is  difficult  to 
separate  the  data,  as  such  from  the  software  and  where  the  data  might  be  an 
intimate  part  of  the  software.  Al  systems,  neural  networks,  and  other  emerging 
technologies  pose  such  problems.  The  SEI  should  further  explore  this  issue. 
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Appendix  C:  Working  Group  C,  Mixed  Funding 
Alternatives 

Issues 

OVERVIEW 


The  focus  of  Working  Group  C  will  be  to  examine  alternatives  for  allocating  rights  in  soft¬ 
ware  in  situations  in  which  both  public  and  private  funds  are  used  in  the  development  effort. 
This  group  will  also  address  the  related  issue  of  defining  the  term  "developed"  for  purposes 
of  determining  whether  software  has  been  "developed  at  private  expense."  Our  research 
has  indicated  that,  because  of  the  unique  nature  of  software,  the  definition  of  such  terms 
may  differ  from  that  which  would  be  appropriate  to  technical  data. 

In  addressing  this  complex  area,  the  working  group  may  wish  to  focus  on  the  following  is¬ 
sues: 

•  What  definition  should  be  adopted  for  the  term  "developed"  for  purposes  of  de¬ 
termining  whether  a  software  product  has  been  "developed  at  private 
expense"? 

•  How  should  a  software  rights  policy  define  those  situations  in  which  a  mixed 
funding  alternative  would  be  triggered? 

•  What  allocation  of  rights  between  the  DoD  and  the  developer  would  be  appro¬ 
priate  in  mixed  funding  situations? 

•  What  would  be  an  appropriate  allocation  of  rights  in  privately  developed  soft¬ 
ware  that  has  been  slightly  modified  at  government  expense? 

•  Should  greater  flexibility  be  afforded  to  contracting  personnel  in  negotiating  with 
respect  to  mixed  funding  software? 

The  product  of  this  working  group  should  be  a  series  of  recommendations  reflecting  the 
group’s  consensus  as  to  the  regulatory  treatment  of  each  of  the  five  primary  issues.  If  pos¬ 
sible,  a  rationale  for  each  recommendation  should  be  included.  If  consensus  cannot  be 
reached  on  a  particular  topic,  a  description  of  the  problems  as  to  why  the  group  could  not 
agree  should  be  provided.  Members  should  feel  free  to  submit  minority  position  statements. 

In  analyzing  these  issues,  the  group  may  find  it  useful  to  attempt  to  address  the  subissues 
set  forth  below.  Please  note  that  these  subissues  are  suggested  only  as  a  starting  point  and 
that  members  of  the  group  should  feel  free  to  formulate  their  own  approaches  to  addressing 
these  issues. 


CMU/SEI-87-TR-13 


June  1987 


49 


I.  WHAT  DEFINITION  SHOULD  BE  ADOPTED  FOR  THE  TERM  "DEVELOPED"  FOR 
PURPOSES  OF  DETERMINING  WHETHER  A  SOFTWARE  PRODUCT  HAS  BEEN  DE¬ 
VELOPED  AT  PRIVATE  EXPENSE? 

I .  When  Is  software  developed? 

There  are  many  people  who  would  argue  that  a  software  product  is  sufficiently  different  from 
technical  data  as  to  warrant  a  different  definition  for  the  term  "developed",  as  used  in  deter¬ 
mining  the  point  at  which  the  product  has  been  developed. 

(a) .  Should  there  be  a  different  definition  for  the  term  "developed"  when  applied  to  software 
as  opposed  to  technical  data? 

(b) .  What  would  be  the  rationale  for  a  different  definition  for  the  term  "developed”  when 
applied  to  software  as  opposed  to  technical  data?  That  is,  in  what  respect  is  software  differ¬ 
ent  from  technical  data  for  purposes  of  determining  the  point  at  which  it  will  be  considered 
developed? 

(c) .  What  aspects  of  the  development  process  should  be  considered  in  determining 
whether  a  software  product  has  been  brought  to  the  point  at  which  it  has  been  developed? 
Should  it  be  an  operational  definition?  Should  it  include  testing?  Should  it  be  based  on 
whether  the  product  has  been  fixed  in  a  "tangible  medium  of  expression"? 

(d) .  In  what  ways  will  the  economics  of  the  software  development  process  influence  the 
definition  of  the  term  "developed"? 

II.  HOW  SHOULD  A  SOFTWARE  RIGHTS  POLICY  DEFINE  THOSE  SITUATIONS  IN 
WHICH  A  MIXED  FUNDING  ALTERNATIVE  WOULD  BE  TRIGGERED? 

1 .  How  can  an  appropriate  mixed  funding  approach  be  defined? 

Congress  has  mandated  that  the  DoD  adopt  a  mixed  funding  alternative,  but  did  not  provide 
guidance  as  to  its  structure.  There  has  been  some  criticism  of  the  approach  of  basing  a 
mixed  funding  alternative  on  a  formula  geared  to  the  percentage  of  public  and  private  fund¬ 
ing  which  goes  into  a  development. 

(a) .  How  might  a  more  workable  mixed  funding  alternative  be  structured? 

(b) .  What  would  be  considered  as  contributions  to  the  development  effort,  and  how  would 
they  be  valued?  Would  a  contractor’s  preexisting  knowledge  base  be  considered?  Would 
use  of  privately  developed  design  and  development  tools  be  considered? 

(c) .  What  would  be  included  in  determining  the  government’s  contribution? 

(d) .  Would  the  approach  suggested  in  the  proposed  FAR  technical  data  regulations  be 
workable? 
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2.  How  should  resource  contributions  be  treated? 


A  mixed  funding  situation  might  arise  in  the  form  of  both  public  and  private  contributions  to 
an  ongoing  development  (concurrent  development),  or  as  an  improvement,  at  private  ex¬ 
pense,  to  a  software  product  which  had  been  developed  at  public  expense  (sequential 
development). 

Should  a  mixed  funding  alternative  apply  to  sequential  development  as  well  as  concurrent 
sharing  of  resources? 

III.  WHAT  ALLOCATION  OF  RIGHTS  WOULD  BE  APPROPRIATE  IN  MIXED  FUNDING 
SITUATIONS? 

1 .  How  should  rights  be  allocated  between  the  DoD  and  the  private  sector? 

Once  It  is  determined  that  mixed  funding  treatment  is  appropriate  in  certain  situations,  the 
allocation  of  rights  between  the  DoD  and  the  developer  must  be  examined.  Such  rights 
might  supplement  or  replace  the  present  categories  of  unlimited  rights  and  restricted  or 
limited  rights. 

(a) .  What  package(s)  of  rights  should  be  available  in  mixed  funding  situations? 

(b) .  Would  government  purpose  rights  be  appropriate?  In  what  instances? 

(c) .  Should  there  be  a  sliding  scale  of  rights  based  on  contributions  made? 

(d) .  Should  some  new  allocation  of  rights  be  structured? 
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V.  WHAT  WOULD  BE  AN  APPROPRIATE  ALLOCATION  OF  RIGHTS  BETWEEN  THE 
DOD  AND  THE  DEVELOPER  IN  PRIVATELY  DEVELOPED  SOFTWARE  THAT  HAS  BEEN 
SLIGHTLY  MODIFIED  AT  GOVERNMENT  EXPENSE? 

1 .  What  rights  should  the  DoD  acquire  In  slightly  modified  software  ? 

The  DoD  will  sometimes  request  that  a  vendor  make  a  slight  modification  to  a  privately  de¬ 
veloped  software  product  so  as  to  make  the  product  applicable  to  some  the  DoD  use.  Be¬ 
cause  the  product  has  been  modified  at  government  expense,  the  DoD  can  claim  unlimited 
rights  in  the  product.  This  reportedly  has  deterred  software  developers  from  modifying  inno¬ 
vative  proprietary  software  for  the  DoD  use. 

(a) .  What  rights  should  the  DoD  acquire  in  privately  developed  software  which  has  been 
slightly  modified  at  public  expense? 

(b) .  Should  it  differ  from  other  situations  in  which  both  public  and  private  funds  have  been 
used  to  develop  the  software? 

(c) .  How  can  the  proprietary  interests  of  the  contractor  be  protected  in  situations  where 
software  has  been  slightly  modified  at  government  expense? 

V.  SHOULD  GREATER  FLEXIBILITY  BE  AFFORDED  TO  CONTRACTING  PERSON¬ 
NEL  IN  NEGOTIATING  WITH  RESPECT  TO  MIXED  FUNDING  SOFTWARE? 

1 .  Can  the  regulations  regarding  mixed  funding  provide  some  flexibility  for  contract¬ 
ing  personnel? 

There  are  many  people  who  feel  that  the  present  the  DoD  technical  data  regulations  are  too 
rigid,  and  that  they  do  not  allow  for  enough  flexibility  in  the  acquisition  negotiation  process. 
Others  are  concerned  that  government  contracting  personnel  require  extensive  structure  to 
ensure  that  the  interests  of  the  government  are  adequately  represented  during  negotiations. 

(a) .  How  much  negotiating  flexibility  should  the  regulations  allow  to  government  contracting 
personnel  in  mixed  funding  situations? 

(b) .  How  could  greater  flexibility  be  obtained  while  still  ensuring  that  the  interests  of  the 
government  are  adequately  represented  during  the  negotiating  process? 
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Working  Group  C  on  Mixed  Funding  Alternatives:  Draft 
Recommendations 


I.  Defining  the  term  "developed"  for  purposes  of  determining  whether  software  has 
been  developed  at  private  expense. 

A.  Proposed  Definition  of  "Developed"  (Government  View) 

The  following  definition  for  the  term  "developed"  was  put  forth  by  the  government  partic¬ 
ipants  in  Working  Group  C  and  is  intended  to  provide  for  the  government’s  maintenance  and 
enhancement  needs. 

Competition  Enhancement  Position 

"Developed",  as  used  in  this  subpart,  means  that  the  computer  software  exists  and  works  as 
intended.  For  the  purpose  of  this  definition,  "To  exist"  the  computer  software  must  be  in  the 
form  of  a  computer  program.  Computer  software  "works  as  intended"  when  that  software 
has  been  analyzed  and  tested  sufficiently  to  demonstrate  to  reasonable  persons  skilled  in 
the  applicable  art  that  there  is  a  high  probability  that  it  will  successfully  operate  for  its  in¬ 
tended  purpose.  How  much  and  what  type  of  testing  is  required,  in  addition  to  analysis, 
depends  on  the  nature  of  the  computer  software  and  the  state  of  the  art. 

B.  Proposed  Definition  of  "Developed"  (Industry  View) 

The  following  definition  for  the  term  developed  was  put  forth  by  private  sector  participants  in 
Working  Group  C  and  was  intended  to  provide  an  equitable  resolution  to  the  issue  of  when 
software  has  been  developed  at  private  expense. 

"Developed"  as  used  in  this  subpart  shall  mean  with  respect  to  computer  software  that  suf¬ 
ficient  documentation  exists,  in  the  form  of  detailed  program  design  specifications,  to  dem¬ 
onstrate  to  a  reasonable  person  skilled  in  the  applicable  art  that  there  is  a  high  probability 
that  such  computer  software  will  operate  as  intended.  A  working  model  of  such  computer 
software  or  components  thereof  will  normally  be  required  only  when  such  a  high  probability 
is  not  found.  To  be  considered  "developed"  the  computer  software  need  not  be  at  the  stage 
where  it  could  be  offered  for  sale  or  sold  on  the  commercial  market.  [As  used  herein, 
"computer  software"  includes  related  documentation]. 

C.  Compromise  Proviso  for  Definition  of  "Developed" 

The  following  proviso  was  derived  from  materials  included  in  the  Packard  Commission  re¬ 
port.  The  private  sector  participants  were  willing  to  accept  the  Proposed  Definition  of 
"Developed"  (Government  View)  presented  in  subsection  A,  above,  on  the  condition  that  this 
proviso  be  attached. 

This  will  be  a  proviso  applicable  to  a  definition  of  developed  that  requires  testing. 
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If  the  computer  software  exists,  then  testing  of  such  computer  software  under  the  contract 
will  be  used  to  establish  whether  or  not  such  software  was  developed  "at  private  expense". 
If  no  significant  modifications  are  performed  under  the  contract  in  order  to  satisfy  the  ap¬ 
plicable  tests,  then  the  software  will  be  considered  to  have  been  developed  "at  private 
expense".  If  significant  modifications  to  such  computer  software  are  performed  under  the 
contract  to  satisfy  the  applicable  tests,  then  this  fact  establishes  that  the  computer  software 
was  not  developed  "at  private  expense". 

D.  Model  to  Guide  Discussion  of  Definition  of  "Developed" 

A  model  used  to  guide  discussions  related  to  defining  the  term  "developed"  appears  below. 


Figure  1 :  Model  Used  in  Defining  "Developed" 
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II.  Trigger  mechanism  for  mixed  funding  alternative 


When  is  funding  mixed? 

Substantial  monetary  contribution  by  both  parties. 

Should  "substantial"  be  defined  to  mean  a  particular  percentage? 

May  need  a  percentage  to  avoid  disputes  over  the  meaning  of  terms  such  as  material  or 
substantial. 

There  was  some  agreement  as  to  10%  as  a  percentage  for  determining  if  the  contribution 
had  been  substantial,  but  there  was  not  a  consensus  as  to  this. 

III.  Minimum  rights  In  mixed  funding  software 


A.  Consensus: 

Negotiation  of  data  rights  is  appropriate  and  desirable  in  mixed  funding  situations. 

B.  Consensus: 

Government  should  have  certain  clearly  defined  minimum  rights  in  all  mixed  funding  situa¬ 
tions. 

C.  Government  View  as  to  Government  Minimum  Rights 

Minimum  rights  in  mixed  funding  situations  should  be  close  to  unlimited  rights. 


Government  purpose  license  rights  may  be  an  appropriate  minimum  standard,  but  the 
obligations  of  the  government  to  protect  the  data  (software)  should  be  clearly  articulated. 


Competitive  reprocurement  and  competitive  maintenance  are  the  heart  of  the  problem. 

Government  perspective:  Government  purpose  rights  require  the  government  to  police  or 
administer;  unlimited  rights  are  preferable  because  the  government  has  no  responsibility 
with  respect  to  the  software  once  it  has  been  released  into  private  hands  for  the  purpose  of 
competitive  reprocurement  or  maintenance. 

D.  Industry  View  as  to  Government’s  Minimum  Rights 

(note:  not  monolithic) 


Minimum  rights  should  not  include  the  rights  to  disclose  for  competitive  reprocurement  or 
competitive  maintenance.  Government  rights  should  increase  as  government  funding  in¬ 
creases  and  as  time  passes. 
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Appropriate  minimum  rights  in  mixed  funding  situations  may  be  the  four  "restricted  rights" 
the  government  gets  in  software  developed  wholly  at  private  expense.  The  four  minimum 
rights  were  generally  acceptable  to  the  private  sector  participants,  although  there  was  some 
feeling  that  the  right  to  modify  might  not  be  appropriate  in  all  situations. 


E.  Some  Thoughts  Put  Forward  by  Mr.  Len  Rawicz  on  Development  of  Computer 
Software  and  Mixed  Funding 

A  At  Private  Expense 

I.  Government  License  Rights 

a.  Four  minimum  positive  rights 

b.  No  negative  covenants 

c.  Can  add  additional  limitations 

d.  Software  documentation  either  unlimited  (manuals)  or  limited 
rights  or  copyright 

II.  Level  of  Software  Deliverables 

a.  Not  specified  by  DFARS 

b.  Contracting  officer  must  consider  level  of  software  deliverables 
based  on  need 

1.  Object  code 

2.  Source  code 

3.  Documentation 

4.  Software  Tools 

III.  Competitive/Maintenance/Enhancement 

a.  Not  specified  in  DFARS  27.4  except  ” right  to  modify" 

b.  Contracting  officer  must  consider  -  acquire  downstream  rights 
and  information  if  competitive  reprocurement  or  competitive 
maintenance  is  needed 

B.  At  Government  Expense 

I.  A.  Government  Rights 

a.  Unlimited  Rights,  or 

b.  Government  purpose  copyright  license  of  all  exclusive  rights 
under  copyright  laws,  and/or 

c.  Contract  limitations  on  right  to  use  internally,  release  for 
competitive  purposes  or  for  maintenance  or  enhancement. 
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I.  B.  Contractor  Rights 

a.  Unlimited  Rights,  or 

b.  Copyright  ownership  (for  commercial  purposes),  or 

c.  Trade  secret  if  sufficient  contract  rights  are  obtained  ( ?) 

II.  Level  of  Software  Deliverables 

a.  Not  specified  by  DFARS 

b.  Contracting  officer  must  specify  (assume  it  will  be  source  code 

and  documentation) 

III.  Comoetitive/Maintenance/Enhancement 

a.  Informational  requests  not  specified  in  DFARS  27.4 

b.  Sufficient  rights  are  available 


Figure  2:  Proposed  Mixed  Funding  Approach 
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F.  Some  Thoughts  Put  Forward  by  a  Private  Sector  Participant  on  Allocation  of 
Rights  In  Software 

These  proposals  for  allocation  of  rights  in  software  were  provided  by  a  private  sector  partic¬ 
ipant.  Unfortunately,  time  did  not  allow  discussion. 

The  government  shall  have  government  purpose  rights  in  computer  software  pertaining  to 
items,  components  or  processes  for  which  the  contractor  has  funded,  or  will  fund  any  of  the 
development  cost  of  the  item,  component  or  process. 

The  government  shall  have  "restricted  rights"  in  computer  software  pertaining  to  items,  com¬ 
ponents,  and  processes  developed  exclusively  at  private  expense. 

The  government  shall  have  "unlimited  rights"  in  computer  software  pertaining  to  items,  com¬ 
ponents  and  processes  developed  exclusively  at  government  expense. 

The  government  may  agree  to  waive  these  "unlimited  rights"  provided  that  the  United  States 
receives,  as  a  minimum,  a  royalty-free  license  to  use,  release,  or  disclose  the  computer  soft¬ 
ware  for  purposes  of  the  United  States,  including  purposes  of  competitive  procurement. 

Such  terms  as  "adaptation"  and  "modify"  shall  mean  and  be  used  to  signify  revisions  made 
to  computer  program  items,  components,  or  processes  in  machine  readable  form,  which  had 
previously  been  "developed". 

IV.  Slight  modification  under  government  contract  of  software  developed  at  private 
expense. 

1.  Does  it  meet  the  standard  for  "developed"  prior  to  government  funding? 

2.  Was  it  modified  with  government  funds? 

If  the  answers  to  questions  1  and  2  are  yes,  the  critical  question  then  becomes: 

3.  Is  the  modification  severable  from  the  original  privately  developed  software? 

If  no,  then  go  to  a  mixed  funding  analysis. 
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Appendix  D:  Summary  of  Software  Rights  in  Data 
Survey 

I.  Introduction 

The  purpose  of  the  Software  Rights  in  Data  Survey  was  to  determine  the  needs  and  con¬ 
cerns  of  the  DoD  and  industry  with  respect  to  key  issues  affecting  the  new  rights  in  software 
policy.  The  survey’s  aim  was  to  supplement  and  refine  the  information  obtained  from  our 
project  interviews  and  workshop.  Although  the  interviews  had  helped  us  to  identify  the  key 
1  issues,  they  were  not  optimal  for  collecting  detailed,  objective  information.  The  workshop 

enabled  us  to  determine  whether  consensus  was  possible  on  some  of  the  issues,  but  intro¬ 
duced  the  effects  of  small  group  dynamics  through  which  a  vocal  or  persuasive  member  can 
narrow  or  distort  the  range  of  opinions  that  emerge.  The  survey  allowed  us  to  capture  the 
entire  distribution  of  opinion  with  enough  detail  to  support  the  conclusions  of  the  workshop 
while  being  independent  of  it. 

II.  Method 

A.  Survey  Population  and  Sample 

We  planned  to  use  the  survey  to  extend  the  breadth  of  our  coverage  of  the  two  populations 
from  which  we  interviewed:  industry  managers  and  lawyers  who  are  knowledgeable  in  data 
rights,  and  the  DoD  technical  personnel  and  program  managers.  In  selecting  our  sample, 
we  found  it  efficient  to  use  the  contacts  that  we  had  made  over  the  more  than  two-year  life 
of  our  project.  Since  we  did  not  attempt  to  sample  scientifically  from  all  industry  lawyers  or 
the  DoD  software  personnel,  but  rather  those  we  knew  to  be  experienced  in  this  area,  our 
results  undoubtedly  represent  more  informed  positions  than  those  held  by  the  populations  at 
large. 

The  government  sample  size  was  141 ,  with  representation  from  all  three  services.  Addition¬ 
ally,  a  sprinkling  of  other  government  and  DoD  agencies,  including  the  Defense  Logistics 
Agency  and  NASA,  were  represented  in  the  sample. 

The  industry  sample  size  was  288,  which  included  both  large  and  small  companies.  Ap¬ 
proximately  20%  of  the  firms  responding  were  small  businesses. 

B.  Response  Rates 

The  overall  response  rate  to  the  survey  was  34%,  but  the  response  rate  was  markedly 
greater  for  the  DoD  sample  (50%)  than  for  the  industry  sample  (26%).  However,  in  many 
cases  more  than  one  survey  was  sent  to  a  single  company,  and  often  only  a  single  survey 
was  returned,  which  mitigates  the  lower  response  rate  for  industry.  A  total  of  51  different 
companies  responded  to  the  survey. 

In  addition,  it  is  likely  that  many  people  in  the  sample  did  not  return  the  questionnaire  be¬ 
cause  they  did  not  consider  themselves  knowledgeable  enough  about  data  rights  issues. 
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We  asked  respondents  to  evaluate  their  expertise  in  this  area,  and  very  few  of  those  we 
received  indicate  less  than  moderate  expertise. 

C.  Question  Design 

Although  the  survey  questionnaires  were  different  for  the  DoD  and  industry,  we  tried,  where 
possible,  to  use  identical  questions  which  would  enable  precise  comparisons  between  the 
two  groups  on  certain  issues.  In  other  cases,  we  were  able  to  ask  complementary  questions 
of  both  groups  that  provide  cross-checks  on  the  reasonableness  and  precision  of  the  re¬ 
sponses. 

Many  of  the  questions  asked  about  the  frequency  of  past  events  or  the  perceived  likelihood 
of  future  events.  These  are  difficult  questions  to  ask  precisely  in  surveys,  and  the  approach 
usually  taken  in  surveys  has  significant  limitations.  What  is  typically  done  is  to  have  respon¬ 
dents  check  one  of  a  set  of  words  that  designate  frequency  categories,  such  as  "never," 
"occasionally,"  "seldom,"  "often,"  "usually,"  and  "always."  But  these  words  mark  neither 
precise  nor  unambiguous  points  on  the  frequency  continuum,  so  using  them  makes  it  diffi¬ 
cult  to  calculate  any  summary  measure  of  "average  frequency." 

Accordingly,  we  devised  a  graphical  estimation  technique  that  turned  out  to  be  both  novel 
and  natural  for  respondents  to  use,  while  providing  more  reliable  and  precise  estimates  of 
the  frequency  of  past  events  or  the  likelihood  of  future  events.  We  presented  a  question 
with  a  line  whose  endpoints  were  labeled  never  and  always,  and  asked  the  respondents  to 
mark  a  point  on  the  scale. 

NEVER . . . . ALWAYS 

This  is  a  form  of  "magnitude  estimation,"  a  measurement  technique  first  studied  by  Stevens. 
Stevens,  The  direct  estimation  of  sensory  magnitude  —  loudness.  American  Journal  of  Psy¬ 
chology,  1956,  69,  1-25.  For  an  introductory  treatment,  see  P.  H.  Lindsay  and 

D.  A.  Norman,  An  introduction  to  psychology,  2nd  ed.  Academic  Press,  1977,  Appendix  A. 

Hundreds  of  experimental  studies  have  since  shown,  almost  counter  to  intuition,  that  asking 
subjects  to  make  direct  estimates  of  subjective  magnitude  give  more  reliable  judgments  than 
more  complex  measurement  instructions.  Elaborate  numerical  and  categorical  scales  al¬ 
most  always  make  things  worse,  because  people  can  let  what  they  know  about  numbers 
and  language  get  in  the  way  of  their  subjective  responses. 

D.  Analysis 

The  unconventional  graphical  response  technique  which  we  used  enabled  us  to  calculate 
meaningful  summary  statistics  but  posed  some  interesting  analysis  issues.  The 
respondent’s  mark  on  the  100mm  scale  between  never  and  always  was  easily  transformed 
to  a  number  between  1  and  100.  Respondents  generally  made  small  and  careful  marks  on 
the  response  scale,  which  gives  us  confidence  that  their  estimates  can  be  meaningfully 
averaged.  However,  at  the  ends  of  the  scale  responses  were  much  less  precise,  and  we 
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sense  that  many  responses  that  were  meant  to  be  never  were  recorded  as  ”5"  and  many 
that  were  meant  to  be  always  were  recorded  as  "95."  We  point  this  out  because  it  implies 
that  our  statistical  claims  are  conservative  if  extreme  observations  are  effectively  weighted 
less  heavily  than  data  points  closer  to  the  central  tendency. 

E.  Presentation  of  Results 

The  following  sections  summarize  the  results  of  the  two  surveys.  In  order  to  ensure  that  the 
results  are  understood  by  the  reader,  we  must  first  explain  some  of  the  conventions  we  use 
in  describing  our  findings.  When  we  say  that  something  happens  "54%  of  the  time"  this 
means  that  the  average  graphical  response  on  the  never...always  scale  was  54%  of  the 
distance  from  never  to  always.  Sometimes,  the  average  isn’t  a  fair  characterization  of  the 
responses,  because  the  responses  weren’t  normally  distributed  (following  the  common  bell¬ 
shaped  curve).  In  those  situations,  where  a  large  number  of  never  or  always  responses 
are  part  of  the  average,  we  generally  emphasize  the  proportion  of  extreme  positions.  When 
the  mean  isn’t  a  good  characterization  of  distribution,  because  it  isn’t  normal  (bell-shaped) 
and  contains  many  extreme  positions,  we  will  point  out  the  percentage  of  never  or  always 
responses. 

III.  Summary 


A.  Scope  of  the  Software  Policy 

The  current  DoD  data  rights  regulations  define  software  to  include  data  bases  and  programs 
in  machine  readable  form.  The  issue  posed  to  survey  participants  was  that  if  this  definition 
were  to  be  changed  in  a  software  rights  policy,  which  items  should  be  included  within  the 
definition  of  software.  A  majority  of  the  respondents  from  both  surveys  felt  that  source  code, 
design  documents,  user  manuals  and  requirements  documents  should  be  included  in  a 
revised  definition  of  software.  A  majority  of  industry  respondents  also  favored  the  inclusion 
of  maintenance  and  installation  manuals  in  the  revised  definition. 

Additionally,  industry  and  DoD  participants  identified  other  items,  such  as  micro  code, 
firmware,  specifications  and  listings  which  should  be  included  within  the  definition  of  soft¬ 
ware.  Table  1  depicts  the  relative  percentages  of  the  DoD  and  industry  survey  participants 
who  indicated  that  certain  items  were  to  be  part  of  the  definition  of  software  within  the  policy. 

This  survey  data  reflects  the  clear  preference  of  both  the  DoD  and  industry  that  the  new 
software  policy  cover  more  than  just  object  code  but  also  key  documentation,  firmware  and 
micro  code. 

B.  DoD  and  Industry  Needs 

1 .  Software  Support  vs.  Industry’s  Need  to  Protect  In  order  to  elicit  information  about  DoD 
needs,  respondents  were  asked  how  frequently  they  needed  to  modify  and  correct  software. 
DoD  personnel  indicated  they  needed  to  modify  software  67%  of  the  time  and  to  correct 
software  acquired  from  contractors  70%  of  the  time.  Moreover,  42%  of  industry  respon- 
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dents  indicated  that  the  DoD  should  always  have  the  right  to  modify  software  developed  for 
it  at  public  expense. 

Survey  participants  were  asked  to  identify  the  types  of  documentation  needed  to  use,  modify 
and  correct  the  software.  The  items  that  were  identified  as  necessary  for  software  use  in¬ 
clude  source  code,  user  manuals,  installation  manuals,  maintenance  manuals,  design  docu¬ 
ments,  testing  information  and  data,  software  tools  used  in  developing  the  software,  and 
requirements  documentation.  In  order  to  to  correct  and  modify  software,  the  following  items 
were  identified  as  being  needed:  source  code,  user  manuals,  maintenance  manuals,  design 
documents,  testing  information  and  data,  software  tools  used  in  developing  the  software  and 
requirements  documentation.  Additionally,  installation  manuals  were  identified  as  necessary 
for  software  modification.  Table  2  reflects  how  frequently  the  items  were  identified  as  nec¬ 
essary  to  correct,  modify  and  use  software. 

DoD  respondents  reported  problems  (56%  of  the  time)  in  obtaining  access  to  needed  docu¬ 
mentation  for  software  that  had  been  developed  by  contractors.  The  types  of  software  tech¬ 
nology  that  contractors  are  most  likely  to  withhold  from  the  DoD  are  source  code,  design 
documents,  designer  notes,  and  software  tools.  Industry  respondents  confirmed  that  they 
have  withheld  privately  developed  software  technology  from  the  DoD  because  of  the  data 
rights  policy. 

The  next  set  of  questions  sought  to  ascertain  how  often  the  DoD  used  third  parties  rather 
than  the  original  developer  to  modify  and  correct  software.  Of  those  responding,  34%  had 
never  used  a  third  party  to  correct  or  modify  software.  This  is  consistent  with  the  industry 
survey  results  reflecting  a  trend  toward  developer  support.  Software  firms  indicated  they 
had  entered  into  agreements  with  the  DoD  to  support  software  developed  by  them  61%  of 
the  time. 

In  those  cases  where  the  DoD  respondents  would  have  used  third  party  contractors  to  sup¬ 
port  software,  they  identified  the  following  items  as  necessary  for  third  party  contractor  sup¬ 
port:  machine  readable  code,  source  code,  user  manuals,  installation  manuals,  maintenance 
manuals,  design  documents,  testing  information  and  data,  software  tools  used  in  developing 
the  software,  and  requirements  documentation. 

Thirty  percent  of  the  industry  participants  indicated  that  the  DoD  should  never  have  the  right 
to  allow  a  third  party  contractor  to  modify  privately  developed  software  that  had  been  sold  or 
licensed  to  the  DoD.  The  average  response  would  allow  the  DoD  this  right  only  41%  of  the 
time.  However,  they  indicated  that  they  had  licensed  documentation  necessary  to  support 
privately  developed  software  to  a  third  party  contractor  only  21%  of  the  time  and  develop¬ 
ment  tools  19%  of  the  time.  Indeed,  51%  of  the  respondents  had  never  licensed  privately 
developed  documentation  or  tools  to  third  party  contractors. 

Despite  the  fact  that  the  majority  had  never  licensed  tools  and  documentation  to  third  party 
support  contractors,  68%  were  willing  to  enter  into  such  arrangements  if  they  were  able  to 
negotiate  the  terms  of  the  license  directly  with  the  support  contractor.  Some  reservations 
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were  expressed  that  the  support  contractor  not  be  a  competitor  of  the  developer.  We  noted 
that  21%  of  the  industry  respondents  indicated  that  under  no  condition  would  they  enter  into 
licensing  arrangements  with  a  third  party  support  contractor. 

The  survey  also  found  that  industry  is  willing  to  place  privately  developed  documentation 
and  tools  into  escrow  with  the  understanding  that  the  DoD  could  gain  access  upon  the  oc¬ 
currence  of  certain  conditions.  Industry  participants  expressed  a  willingness  to  enter  into 
such  escrow  arrangements  the  majority  of  the  time.  The  most  frequently  cited  conditions  for 
release  of  escrowed  tools  and  documentation  were,  the  company  goes  out  of  business,  the 
company  discontinues  the  product  line,  and  a  national  emergency. 

Table  3  reflects  the  percentage  of  respondents  who  would  agree  to  certain  conditions.  Even 
though  three-fourths  of  industry  respondents  had  never  entered  into  escrow  arrangements, 
a  majority  were  willing  to  do  so  under  certain  conditions. 

2.  Innovative  Technology 

The  difficulty  that  the  DoD  has  in  gaining  access  to  innovative  technology  was  highlighted  by 
the  finding  that  71%  of  industry  respondents  indicated  that  at  some  time  they  had  chosen 
not  to  sell  or  license  privately  developed  software  to  the  DoD  because  of  DoD’s  data  rights 
policy.  Moreover,  the  data  indicated  that  29%  of  the  time,  the  DoD  is  losing  access  to 
privately  developed  software.  Technology  which  has  been  withheld  include  software  tools, 
applications  software,  CAD/CAM  programs  and  artificial  intelligence  programs.  Industry 
reluctance  to  license  their  privately  developed  technology  to  the  DoD  was  corroborated  by 
DoD’s  survey  results  which  indicated  that  DoD  organizations  had  encountered  contractors 
or  subcontractors  who  would  not  license  privately  developed  software  technology  to  the 
DoD  35%  of  the  time. 

It  should  be  noted,  however,  that  88%  of  industry  respondents  agreed  that  restrictions  on 
licensing  arrangements  would  make  them  more  willing  to  license  privately  developed  tech¬ 
nology  to  the  DoD.  The  types  of  restrictions  preferred  by  the  majority  of  participants,  in 
order  of  preference,  were  limitations  preventing  the  DoD  from  permitting  parties  outside  the 
DoD  to  make  use  of  or  see  the  software  or  its  documentation,  and  limitations  restricting 
DoD’s  use  to  a  particular  site. 

3.  Commercialization  of  Publicly  Developed  Software 

DoD  and  industry  respondents  differed  sharply  as  to  whether  industry  should  have  the  right 
to  commercialize  software  developed  at  public  expense,  or  to  prepare  and  market  deriva¬ 
tives  of  software  developed  at  public  expense.  Industry  respondents  overwhelmingly  felt 
that  industry  should  have  the  right  to  commercialize  and  prepare  such  derivatives,  while 
among  government  respondents,  a  smaller  majority  felt  that  industry  should  have  the  right  to 
prepare  and  market  the  derivatives  and  only  about  one  third  of  the  respondents  felt  that 
industry  should  have  the  right  to  commercialize  the  publicly  developed  software  itself.  (See 
Table  4.) 
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The  primary  reason  for  this  contrast  stems  from  DoD’s  need  to  release  the  software  outside 
the  DoD  51%  of  the  time.  The  dominant  reason  for  making  software  or  documentation  avail¬ 
able  to  persons  outside  the  DoD  is  for  post-deployment  software  support  (74%  of  the  time). 
Other  reasons  include:  release  to  third  parties  for  reprocurement  purposes  (35%  of  the 
time),  allowing  outside  persons  to  develop  commercial  applications  for  software  (14%  of  the 
time).  Additionally,  independent  verification  and  validation,  making  software  available  as 
GFE,  foreign  military  sales,  and  reuse  were  indicated  by  respondents. 

C.  Copyright  Policy 

Under  current  DoD  policy  a  contractor  may  claim  a  copyright  in  software  developed  at  public 
expense,  subject  to  granting  the  DoD  a  non-exclusive  paid  up  license  to  reproduce  the  work, 
distribute  copies  of  the  work,  display  the  work  publicly,  prepare  derivative  works  and  au¬ 
thorize  others  to  do  so  for  government  purposes.  DoD  and  industry  groups  hold  somewhat 
different  positions  on  copyright  policy.  The  primary  contrast  was  that  45%  of  the  DoD 
respondents  said  that  contractors  should  never  be  permitted  to  copyright  software  devel¬ 
oped  at  public  expense  while  24%  of  the  industry  respondents  said  that  contractors  should 
always  be  allowed  such  copyrights. 

Under  current  policy,  when  a  contractor  claims  the  copyright  in  software  developed  at  public 
expense,  he  is  required  to  affix  to  the  software  a  copyright  notice  and  notice  of  government 
rights  in  the  work.  Survey  respondents  were  asked  to  indicate  what  other  requirements 
should  be  imposed  on  a  contractor  copyrighting,  software  developed  at  public  expense. 
Table  5  reflects  industry  and  government  positions  on  each  of  these  restrictions. 

Interestingly  enough;  despite  the  fact  that  industry  respondents  indicated  a  contractor 
should  be  permitted  to  claim  a  copyright  in  publicly  developed  software  56%  of  the  time, 
they  only  actually  claim  such  a  copyright  21%  of  the  time.  Moreover,  41%  of  respondents 
never  have  claimed  such  a  copyright  in  publicly  developed  software. 
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Tables 


Table  I 

The  current  definition  of  software  in  the  DoD  data  rights  regulations  includes  only  computer 
programs  and  data  bases  in  a  machine  readable  form.  Some  people  feel  that  this  definition 
doesn't  adequately  characterize  software. 

If  this  definition  were  to  be  changed  in  a  software  rights  policy,  which  of  the  following  items 
should  be  included  in  the  definition  of  the  term  "software"? 


Item 

DoD% 

lndustrv% 

Source  Code 

94 

96 

User  Manuals 

54 

58 

Installation  Manuals 

44 

51 

Maintenance  Manuals 

45 

55 

Design  Documents 

67 

69 

Designers’  Notes 

26 

31 

Testing  Information  and  Data 

48 

47 

Configuration  Management  Tools 

32 

23 

Software  Tools  Used 

in  Developing  the  Software 

48 

39 

Requirements  Documentation 

52 

58 
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Table  II 


DoD  Questionnaire 


Use% 

Correct% 

Modifv% 

Source  Code 

74 

97 

99 

User  Manuals 

96 

70 

75 

Installation  Manuals 

80 

49 

54 

Maintenance  Manuals 

64 

61 

64 

Design  Documents 

61 

82 

87 

Designers’  Notes 

25 

34 

39 

Testing  Information  and  Data 

57 

66 

63 

Configuration  Management  Tools 

46 

43 

46 

Software  Tools  Used 

in  Developing  the  Software 

61 

73 

81 

Requirements  Documentation 

59 

72 

67 

Table  III 

Industry  Questionnaire 

Conditions  under  which  industry  participants  would  be  willing  to  allow  the  DoD 
to  gain  access  to  escrowed  proprietary  documentation  and  tools. 


Documentation 

Tools 

Company  Goes  Out  of  Business 

84% 

83% 

Company  Discontinues  Product  Line 

84% 

71% 

A  National  Emergency* 

7% 

8% 

'Although  not  included  as  an  answer  on  the  survey,  several  respondents  wrote  in  that  a 
National  Emergency  would  be  acceptable  grounds  for  releasing  the  documentation  and 
tools  from  escrow. 
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Table  IV 


DoD  and  Industry  Questionnaire 

When  a  contractor  develops  software  with  government  funds  or  a  combination 
of  government  and  private  funds,  under  a  DoD  contract,  and  delivers  it  to 
the  government,  what  should  the  contractor  be  permitted  to  with  it? 


DoD%  lndustrv% 

Retain  right  to  commercialize  the  software  35  81 

Retain  the  right  to  prepare  derivatives 

of  the  software  product  delivered  to  the  government 

and  to  market  them  58  90 

Retain  no  rights  to  commercialize 

and  market  the  software  26  7 

Be  required  to  deliver  all  derivatives 

made  of  the  software  to  the  DoD  26  3 


Table  V 

DoD  and  Industry  Questionnaire 

Other  requirements  which  should  be  imposed  on  a  contractor  copyrighting 
software  developed  at  public  expense: 


DoD% 

lndustrv% 

Seek  permission  from  the  government 

67 

31 

Give  notice  to  the  government 

48 

64 

Agree  to  assign  the  copyright  to  the  government 

59 

31 
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